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

RE: Client Side Session management

From: Duraisami Anandha Krishnan <dkrishna@cordys.com>
Date: Fri, 25 Jun 2004 14:06:50 +0530
Message-ID: <BD910F3633F1BF4FA4879A99AC396FCF794509@ex-ind-u0.vanenburg.com>
To: "Dharmesh Mistry" <dharmesh@edgeipk.com>, "Borkar, Milind (MNPS Contractor)" <milind.borkar@mnps.org>, "Mark Birbeck" <mark.birbeck@x-port.net>
Cc: <www-forms@w3.org>
Hi 
We too do that in our product with lots of flexibility and found this is very good.
Thanks
Regards
anand

-----Original Message-----
From: Dharmesh Mistry [mailto:dharmesh@edgeipk.com]
Sent: 25 June 2004 14:04
To: Borkar, Milind (MNPS Contractor); 'Mark Birbeck'
Cc: www-forms@w3.org
Subject: Re: Client Side Session management


Agreed too.
 
The key consideration here is that XForms must support this for both implementation models (Plug-in and Server based). We have developed server based model for this i.e. we have Javascript libraries that are shipped with the first page, hold data between pages and repopulate previous forms. This works for us, but is "not standard".
 
D
 
 
 
 
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 copy.
 
edge IPK Limited
Registered office - 9 Wardle Avenue, Tilehurst, Reading, Berkshire RG31 6JR
Registered in England No. 4286817

----- Original Message ----- 
From: Borkar,  <mailto:milind.borkar@mnps.org> Milind (MNPS Contractor) 
To: 'Mark Birbeck' <mailto:mark.birbeck@x-port.net>  
Cc: www-forms@w3.org 
Sent: Tuesday, June 22, 2004 4:28 PM
Subject: RE: Client Side Session management


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. 

Regards, 
Milind. 


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

Regards, 

Mark 


Mark Birbeck 
CEO and CTO 
x-port.net Ltd. 
  
Download our XForms processor from 
http://www.formsPlayer.com/ 
  
-----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. 
Regards, 
Milind. 
-----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 


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

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



**********************************************************************
The information in this message is confidential and may be legally
privileged. It is intended solely for the addressee. Access to this message
by anyone else is unauthorized. If you are not the intended recipient, any
disclosure, copying, or distribution of the message, or any action or
omission taken by you in reliance on it, is prohibited and may be unlawful.
Please immediately contact the sender if you have received this message in
error.

**********************************************************************
Received on Friday, 25 June 2004 04:37:52 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 10 March 2012 06:21:58 GMT