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

RE: Client Side Session management

From: Karandikar, Shailesh <Shailesh.Karandikar@dendrite.com>
Date: Tue, 22 Jun 2004 11:39:28 -0400
Message-ID: <3101F58237A7CF468D6F1DB16778EB620C7967BB@diexus1.us.drte.com>
To: "Mark Birbeck" <mark.birbeck@x-port.net>
Cc: <www-forms@w3.org>

For 'realistic-smart-client' applications, there is a need to virtualize
access to the local resources using a model similar to XQuery and
provide a web-session management protocol. This would increase the
complexity of the specs.


-----Original Message-----
From: www-forms-request@w3.org [mailto:www-forms-request@w3.org] On
Behalf Of Mark Birbeck
Sent: Tuesday, June 22, 2004 11: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
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

A transaction on Amazon is no different to this - part of the
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
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
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
that once you complete a database bound transaction, most of the times
will be required to discard the current client data and refresh it from
backend. Plus, maintaining high volume of data on the client side and
'depending' upon it would call for some significant assumptions on
resources , something that could be risky for a web application running
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),
that at most one 
XML instance data section is replaced after a successful submission (the

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
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
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

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)
569 371 

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

you are not the intended recipient, please advise the sender immediately
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
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
> > 
> > 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

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 

This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

Received on Tuesday, 22 June 2004 11:42:03 UTC

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