OASIS Web Services Interactive Applications TC

 View Only

RE: [wsia] [wsrp] [wsrp-wsia joint interfaces] Merged interfacesdocument

  • 1.  RE: [wsia] [wsrp] [wsrp-wsia joint interfaces] Merged interfacesdocument

    Posted 06-11-2002 04:47
     MHonArc v2.5.2 -->
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    

    wsia message

    [Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


    Subject: RE: [wsia] [wsrp] [wsrp-wsia joint interfaces] Merged interfacesdocument


    Andre - my comments are embedded in [CL] tags.
    
    
    Best regards
    Carsten Leue
    
    -------
    Dr. Carsten Leue
    Dept.8288, IBM Laboratory B�blingen , Germany
    Tel.: +49-7031-16-4603, Fax: +49-7031-16-4401
    
    
    
    |---------+---------------------------->
    |         |           Andre Kramer     |
    |         |           <andre.kramer@eu.|
    |         |           citrix.com>      |
    |         |                            |
    |         |           06/10/2002 04:37 |
    |         |           PM               |
    |         |           Please respond to|
    |         |           Andre Kramer     |
    |         |                            |
    |---------+---------------------------->
      >---------------------------------------------------------------------------------------------------------------------------------------------|
      |                                                                                                                                             |
      |       To:       Rich Thompson/Watson/IBM@IBMUS, wsia@lists.oasis-open.org, wsrp@lists.oasis-open.org                                        |
      |       cc:                                                                                                                                   |
      |       Subject:  RE: [wsia] [wsrp] [wsrp-wsia joint interfaces] Merged interfaces  document                                                  |
      |                                                                                                                                             |
      |                                                                                                                                             |
      >---------------------------------------------------------------------------------------------------------------------------------------------|
    
    
    
    Supporting a batch operation mode through arrays does not seem very clean.
    In the "getFragment"
    case (getFragments?), the portal will most likely then have to wait until
    the whole array is
    returned (i.e. all remote portlets have rendered) before it can display the
    resulting mark-up.
    
    [CL] Using the concept of batch processing the consumer could try to
    optimize the relationship between minimal roundtrips and fast response. One
    efficient scnerario that I see is that the consumer wants to display
    portlets from multiple providers on one page. It could the in parallel
    invoke getFragments on each provider passing it a list of all visible
    portlets at this provider. The provider in turn can render the portlets in
    the request in parallel on the server. My feeling is that this gives the
    fastest possible overall rendering time.
    The argument that the consumer would have to gather all output first before
    displaying markup is not only true for batch processing. We defined that a
    getFragments call might return fragments that go to the HEADER or in a
    toolbar. So in any case the consumer will have to fetch the whole markup
    first.
    [CL]
    
    How many consumer to producer parallel calls do we expect typically? I
    would
    rather leave
    call batching up to the (future) SOAP stack.
    
    [CL] whenever that will be ;-) [CL]
    
    
    Always using "Entity" as the thing to create remotely seem to loose the
    "class" versus "object"
    semantics that the WSRP "template" and "instance" operation names used to
    imply. Do we now see no
    no difference between remote data storage - 'templates' (possibly with
    inheritance) and
    computational entities - 'instances', that WSRP seems to naturally call
    for?
    Or are these the
    persistent v.s. transient entities of the document (for me, portlet
    instances persist too)?
    
    [CL] from my understanding all "entities" are comparable to "objects" in a
    normal programming language, not to "classes". Event templates that just
    make the difference design time vs run time
    [CL]
    
    In trying to follow the discussion, I'm confused as to why we need both
    sessions and transient
    entities, both being under the control of the consumer. I do see a need for
    common sessions
    (same user/group or consumer portal) but do not see the need for other
    transient entities,
    expecting a consumer to have to pay for all entities, in some way, in the
    real world. I know
    the next call will discuss these but could someone give a brief rational
    before then?
    
    Thanks,
    Andre
    
    Andre Kramer, Citrix Systems, Inc.