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.