RE: [wsia] RE: [wsrp-interfaces] [wsrp][interfaces] Statemanagement/paramet ers

[Eric VanLydegraf <ericv@kinzan.com>]

Comments tagged as <evl/>

-----Original Message-----
From: Carsten Leue [mailto:CLEUE@de.ibm.com]
Sent: Wednesday, July 24, 2002 12:19 PM
To: Michael Freedman
Cc: wsrp-wsia; interfaces
Subject: Re: [wsia] RE: [wsrp-interfaces] [wsrp][interfaces]
Statemanagement/paramet ers

[...]

Q: How do we support this model when we already know that this will not
work with some browsers/devices (because the URLs will tend to be long,
especially if we don't support stateless stateful portlets...)?
A: Though the model allows navigational parameters/action parameters be
entirely maintained in the links that go all the way back to the client
this isn't required.  A consumer is free to maintain this
information in memory as part of a URL rewriting mechanism.  I would expect
that some portals will choose to run with minimal state [the parameters are
sent back to the client] whereever possible -- i.e. on
the desktop, and support the URL rewrite/parameter caching technique for
wireless/small sized device situations.  Such portals would be oen that
believed most of their requests were desktop requests -- hence
seek an optimal/scalable solution in this environment.

<cl> Definitely. I would assume that only very few portals will encode the
navigational state of all portlet on a page in the URL that gets back to
the client. The URL will soon become much too large, so every portal will
need to implement state management for its portlets.
What worries me a bit is that we make a lot of design compromizes to fulfil
a possibility that will not be the normal use case. What does the group
think?
</cl>
<evl>
For portals I completely agree, but simple Consumers are going to use a low
number of portlets, most likely
just one (sorta a quickie servlet/CGI/ASP(?)/JSPTagLibrary with customized
headers and footers wrapped around a portlet markup) to only 2 or 3 at most
and will just pass along the navigationState through the URL or cookie (2k
limit is plenty for small number case). How realistic the use case I don't
know but that's typically the open source solutions or examples available
today. You can find rather easy one web service call libraries that anybody
can quickly adopt into their project. Is there any use beyond demos I don't
know, it's true that the many aggregation case (typical portal) is more
interesting and appealing, but I'm not sure that the simpleConsumer case is
something to skip though.
</evl>
[...]