State Information as HTML attribute (was: session is as part of URL)

At 8:11 PM 7/26/95, www-talk-request@w3.org wrote:
>Just a reality check on the whole session-id issue --- with regard to
>one server's approach to it.  If you go to Time-Warner's Pathfinder
>site (which is, they claim, one of the busiest on the net, with
>several million hits a week), you find yourself instantly redirected
>to something of the form:
>
>  http://www.pathfinder.com/@@VFNihgAAAAAAQDIL/pathfinder/Quick_Navigator.html
>
>The '@@VFN...' part is (as one quickly discovers by connecting to the
>root page multiple times) a session ID.  The software that does this,
>by the way, is a beta of a commercial server product which may very
>well be turning up elsewhere in the not-so-distant future.

I have for some time used the search-path to pass state information from
one session to another. I have seen several others that do the same. As it
might be useful for this debate, here is a brief about how this is
implemented.

Lets start with a threaded web based bulletin board / conference service
that I have had running since last fall. All pages are created on the fly,
where all links that lead to other pages in the service include the state
information that will create the next page.  An example of an URL for this
service is
<URL:http://rohan.sdsu.edu/cgi-bin/terjen/bb/browse?forum=infosandiego&ids=1
6018252%5F617> Note how the search part of the URL thus contains both a
session id and dynamic state information, and that there is no need for any
information about the user to be stored on the service between requests.
Also, by using the links for such state information rather than an object
on the server, individuals can use the "back" button of the browser without
awkward results.

Another service that have a related architecture is ListMaster, a generic
web interface to post administrative requests to mailing lists. ListMaster
lets service providers create a link that contains various administrative
information for a particular mailing list, by filling out an "authoring"
form with the configuration. This link can then be added to any Web page,
and will upon activation submit the information to a cgi-bin that
on-the-fly creates a tailored interface for this particular mailing list.
This interface contains new links with the preferences included in the
search-path, so the state information is passed along with any new
information in the form and passed to a new cgi, which displays a new page
and eventually emails a request to the listserver.  Here is an example of
an URL for a ListMaster that can be inserted into a link (most browsers do
not manage direct input of such long URLs):

<URL:http://rohan.sdsu.edu/cgi-bin/terjen/listmaster/form?list=www%2dtalk&se
rver=www%2dtalk%2drequest%40mail%2ew3%2eorg&subscribe=subscribe&unsubscribe=
unsubscribe&post=www%2dtalk%40mail%2ew3%2eorg&languages=English&public=on&de
scription=WWW+Developers+Talk&help=Help>

In neither case any information is stored on the service server, with the
scalability advantages that follows (previously discussed on this list).
Feel free to inspect the services, and pay close attention to how the
various  URLs are used to pass state information.

>   Well, here's one case in which this hack *seems* to score high,
>   sorta kinda --- it does, after all, work now.  However, if kludges
>   like this become more widespread, other software may be adapted to
>   deal with them semi-intelligently (caches in particular may want to
>   avoid the problems discussed above), with results which will not be
>   terribly pretty, and will probably be more of a headache for
>   everybody than a session-id mechanism which was thought through
>   from the start.

Yes, this way of passing state information might be innovative, but not
especially elegant. I have therefore suggested that such information can be
passed as an attribute to the anchor (for example called STATE). here is a
quick example based on the Web Forum service mentioned above:

<A HREF="http://rohan.sdsu.edu/cgi-bin/terjen/bb/browse"
STATE="forum=infosandiego&ids=16018252%5F617">InfoSanDiego Discussion</A>

Potentially we can use a more advanced scheme where the attribute-value
from nested containers are inherited to affect all links inside the
container.
Here is a nested example, based on the ListMaster example, with two links
to separate mailing lists on the same listserver. The idea is that the
information in the STATE attribute to the MENU container are merged with
the STATE attribute of the anchor that is activated:

<MENU
STATE="server=majordomo@mail.w3.org&post=[list]@mail.w3.org&subscribe=subscr
ibe&unsubscribe=unsubscribe&languages=English&public=on&help=Help">

<LI><A HREF="http://rohan.sdsu.edu/cgi-bin/terjen/listmaster/form"
STATE="list=www-talk&description=WWW Developers impressing each other with
additions to the standards">WWW-Talk</A>

<LI><A HREF="http://rohan.sdsu.edu/cgi-bin/terjen/listmaster/form"
STATE="list=www-user&description=WWW Users asking silly
questions">WWW-user</A>

</MENU>

State information that are shared on the full document can thus be added to
one of the all-enclosing containers (e.g. HTML) to affect all links in the
document. This nested scheme is important as it reduce the redudancy of
comprehensive state information in documents with many related links, thus
the size of the document (especially important as such hidden state
information takes time to process without providing any visual additions to
the document). Please note that this approach does not exclude other ways
of passing state information, but merely add a dimension to possible uses.
Importantly, it does not directly cover profiles and preferences to be
stored between sessions.

This way of handeling state information and session ids open up for a
number of interesting usages, and appears to be quite flexible and
expandable. I intended to bring this up with some related suggestions at
the upcoming "Workshop on WWW and Collaborative Work" at MIT in September
(as it is very usable for such applications) but would rather see that this
group elaborate on it now as only some of us in the "session id debate" on
this list will be at that workshop.

-- Terje <Norderhaug.CHI@Xerox.com>
   <URL:http://www.ifi.uio.no/~terjen/>

Received on Thursday, 27 July 1995 04:49:24 UTC