RE: Client Side Session management

Bryan,

Although what you say is true, I wonder if Dharmesh is actually after some
way of returning to data later on. As the XForms specification stands the
'many instances' approach requires that you have one big form that has all
possible 'sub-forms' that need to share the same instance data.

An example is something like the salesforce.com CRM web services, which give
users a session ID when they log on. This session ID is needed for each
subsequent request to the server, and there is currently no standard way to
pass this data from one form to another, without passing it up to some
server, and then back again as part of a new form. (There are *non-standard*
ways to do this in formsPlayer, and I'm sure there are in other processors -
but of course, we're all concerned with standards ;).)

This is something that I have been keen on for quite a while, so I'd like to
hear any thoughts and feedback people have. Currently I see three ways that
we could approach this (not all mutually exclusive). The first is already
implemented by some processors.


1. DEFAULT FILE LOCATION
In formsPlayer (and I believe X-Smiles), if you save or load a file from a
*relative* path with the "file" protocol:

  <instance src="file:my-config.xml" />

and the document was not loaded with the "file" protocol (for example, via
HTTP), the file will be read from or saved to a 'per-user' location. In
formsPlayer this is to the desktop. This is partly because you need to make
some decision as to where things should go, since there is no definition of
how to work out the absolute value of a relative URI if it's 'relative' to a
URI from a different protocol. Since I'm pretty sure that X-Smiles does
something similar to us (not to the desktop, but to a user-specific
location) this would give some level of interoperability. Of course,
security concerns mean that in formsPlayer we've had to show an annoying
dialog box, so we're trying to work on this.


2. DYNAMIC URLs
The second way this could be done is by allowing @action on <submission> to
hold an XPath query. This would allow you to set the location for each user
and application. This is of course not supported in XForms 1.0, although is
'in the air' for a future version. It is supported in formsPlayer via the
xforms:extension element, but of course that makes it non-standard.


3. A 'COOKIE' PROTOCOL
Even if either of the first two solutions were available on all XForms
processors, the 'file' protocol shouldn't be trusted. I'd therefore be quite
interested to see a way of expressing some 'known per-user location' via a
URL. That way we could effectively create 'XML cookies':

  <instance src="cookies://my-config.xml" />

We could define 'cookies:' as going to some file location on a per user, per
domain basis, much like cookies do now. This could even work on mobile
devices, since the cookie location could be mapped to a server.

This last approach is my preferred one, and note that it would not need to
be part of the XForms specification.


Any thoughts?

Regards,

Mark


Mark Birbeck
CEO and CTO
x-port.net Ltd.

Download our XForms processor from
http://www.formsPlayer.com/


-----Original Message-----
From: Thompson, Bryan B. <BRYAN.B.THOMPSON@saic.com> 
Date: Tue, 22 Jun 2004 06:33:27 -0400
Message-Id:
<D24D16A6707B0A4B9EF084299CE99B39103DFB3B@mcl-its-exs02.mail.saic.com> 
To: Dharmesh Mistry <dharmesh@edgeipk.com>, www-forms@w3.org 


Yes.

An XForms client can hold multiple XML trees as instance data.  It is my
understanding that
these data either survive a submission (and so are held by the client), or
that at most one
XML instance data section is replaced after a successful submission (the one
whose data was
submitted), or that the entire page is replaced (normal HTML Forms-based
navigation).  The
first and second of these cases are responsive to your request.  They
behavior is controlled
by the "replace" attribute on the "submission" element.

-bryan

-----Original Message-----
From: www-forms-request@w3.org [mailto:www-forms-request@w3.org] On Behalf
Of Dharmesh Mistry
Sent: Tuesday, June 22, 2004 4:12 AM
To: www-forms@w3.org
Subject: Client Side Session management



We have been deploying web applications for a number of years now. Where
possible we have adopted standards, how for transactional web based
applications we have had to question the standard "CGI" model.

One thing we think that would be of massive benefit is client side session
data (more than just cookies) support. Such that data can be held in the
memory of the client. This would enable not having to write code to
repopulate forms. Also would overcome the constant issue of Browser back
buttons picking up cached forms (which then have to be expired so the server
can represent the data).

Received on Tuesday, 22 June 2004 10:17:10 UTC