W3C home > Mailing lists > Public > www-forms@w3.org > June 2004

RE: Client Side Session management

From: Borkar, Milind (MNPS Contractor) <milind.borkar@mnps.org>
Date: Tue, 22 Jun 2004 10:28:43 -0500
Message-ID: <B48F9A0AA879DD40BDA86A22A96A5DA2174A5F@hobsvismb01.nashville.org>
To: 'Mark Birbeck' <mark.birbeck@x-port.net>
Cc: www-forms@w3.org
Hi Mark: 

I agree with your examples and hence I said that this strategy would be more
on a case-by-case basis, and it would be unwise to adapt it 'blindly'. In
the examples you give, the most current data is on the client (server-bound
transactions being few and far between), and hence 'reusing' it from form to
form makes sense - rather it is a must. 


-----Original Message-----
From: Mark Birbeck [mailto:mark.birbeck@x-port.net] 
Sent: Tuesday, June 22, 2004 10:23 AM
To: Borkar, Milind (MNPS Contractor)
Cc: www-forms@w3.org
Subject: RE: Client Side Session management

Hi Milind,

But what about the users who only connect to a server once a week! There are
some applications where users go off and collect data, making use of a
snap-shot of data at the same time, and then periodically connect up and
synchronise. You need both client and server validation for this situation.

A transaction on Amazon is no different to this - part of the transaction
takes place on the client before continuing on a server - it's just
compressed into a shorter timeframe.



Mark Birbeck
x-port.net Ltd.
Download our XForms processor from
-----Original Message-----
From: www-forms-request@w3.org [mailto:www-forms-request@w3.org] On Behalf
Of Borkar, Milind (MNPS Contractor)
Sent: 22 June 2004 15:56
To: 'www-forms@w3.org'
Subject: RE: Client Side Session management

I am relatively new to the X-Form forum, but here is my doubt on this
approach - How much 'trust' could you show in the data client side data
'without' being validated/manipulated/massaged by the server? The general
web development guidelines for security dictate that each element be
revalidated on the server side, and most of the times the data (such as
derived data) is computed on the server. 
To take a similar situation on the client-server side, applications are
required to refresh their client data once a server-bound transaction is
completed. This ensures the currency and integrity of the data. 
I realize that there are performance benefits in retaining data on the
client side, but would that not be more on a case-by-case basis? I believe
that once you complete a database bound transaction, most of the times you
will be required to discard the current client data and refresh it from the
backend. Plus, maintaining high volume of data on the client side and
'depending' upon it would call for some significant assumptions on client
resources , something that could be risky for a web application running on
diverse platforms. 
-----Original Message----- 
From: Thompson, Bryan B. [mailto:BRYAN.B.THOMPSON@saic.com] 
Sent: Tuesday, June 22, 2004 5:34 AM 
To: Dharmesh Mistry; www-forms@w3.org 
Subject: RE: Client Side Session management 

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. 
-----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). 
Is this issue being addressed by XForms / W3C ? 

Dharmesh Mistry 
Chief Operating and Technology Officer, edge IPK 
E dharmesh@edgeIPK.com 
M +44 (0)  7789 222 015 
Newbury Office                   T  +44 (0) 1635 231 231    F  +44 (0) 1635 
569 371 

This message may contain information which is confidential or privileged. If

you are not the intended recipient, please advise the sender immediately by 
reply e-mail and delete this message and any attachments without retaining a

edge IPK Limited 
Registered office - 9 Wardle Avenue, Tilehurst, Reading, Berkshire RG31 6JR 
Registered in England No. 4286817 
----- Original Message ----- 
From: "Jason Harrop" <jharrop@speedlegal.com> 
To: <www-forms@w3.org> 
Sent: Tuesday, June 22, 2004 2:36 AM 
Subject: IE rebirth - and XForms support 

> http://blogs.msdn.com/dmassy/archive/2004/06/16/157263.aspx says: 
> > "I'm returning to work on the Internet Explorer team.  .. ... I'm 
> > very 
excited to be returning to the team where we clearly have much work to do. 
> > 
> > What am I going to be doing? I'll be on the Program Management team 
focusing on helping customers and bringing customer feedback to the team. ..

> > 
> > What are we planning for Internet Explorer? Tony Chor the Group 
> > Program 
Manager on the team put it well on Channel 9. At this stage there isn't much

more to add other than to reiterate the point that the Internet Explorer 
team does exist and does care. In my new job role I'm very interested in 
hearing about what you the customers would like to see. .. 
> See the blog for more details on how to request XForms support in 
> Internet Explorer, if you are minded to. 
> cheers, 
> Jason 
Received on Tuesday, 22 June 2004 11:29:24 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:36:13 UTC