RE: AJAX vs. Xforms

Raman,

I second your thoughts, except that you didn't mention FormFaces;-(

Kidding aside, the debates between client-side to server-side XForms
processing models is for the most part perhaps a tad destructive from an
outsider looking in, deciding whether or not to use XForms. If I wasn't
already bought in, I would have serious doubts betting my ROI on using
this technology from what is being said within the XForms forum itself
... I've said this before and I'm bringing it up again.

We need to pull together ... Raman makes some very adhesive points about
XForms processing models. I believe it would behoove everyone if we
derived usage scenarios with respect to processing models, much like
what SOAP did. I am a true believer there is not one cure for all.

We are system architects, which means accessing the requirements to a
particular problem and choosing the appropriate solution to maximize ROI
... In many simple cases it may not involve XForms at all.

Below are a couple clarifications to comments passed through my email:

1. To say client-side XForms processing is broken because email
addresses are exchanged in the open - I say to the system architect,
decide what you want to keep behind the firewall and implement it.

2. To say server-side XForms processing is broken because it requires to
many round trips - I say to the system architect, determine the number
of round trips required and make a system trade-off.

3. To say server-side XForms processing is required to increment across
large datasets on the server is not accurate - Client side processors
can do this as well.

4. ... And there are many more ...

XForms and resulting XForms processor solutions are additional tools for
system architects to choose from based on their specific requirements.
Much of the debate going on I believe is either context based which
varies significantly or from the purist view point that if it can't
solve everything it has no value.

I suggest we derive usage scenarios to help guide the online form
industry looking at us leading this effort. This will present a
constructive approach to what fits where. For example, FormsPlayer(sorry
Mark) is an easy target because plug-ins are easy to talk negative
about. But in reality, there are many markets in which this would be
okay because many companies and business partners use uSoft-only
solutions.

So one, I would like to here if defining usage scenarios is a good idea
or not. And two, if it is a good idea, how do we move forward.

Very respectfully,
Gary  
 

-----Original Message-----
From: www-forms-request@w3.org [mailto:www-forms-request@w3.org] On
Behalf Of T.V Raman
Sent: Monday, November 07, 2005 19:50
To: jeacott@hardlight.com.au
Cc: efisher@fsystems.com; www-forms@w3.org
Subject: Re: AJAX vs. Xforms



Stepping back a bit from the "XForms only on client" vs "XForms only on
server", when we designed XForms, we considered *all* of these use-cases
and more.

An important feature of the XForms design, and one that has led to the
plethora of implementations ranging from purely server-side XForms to
complete client-side implementations is the event-based design of the
XForms Processing Model.

When people discuss and debate XForms, what often gets debated is the
XML syntax, the XML model, the XML UI ... But what gets rarely talked
about, and should probably be given more attention, is the overall
XForms Processing Model that allows you to implement an XForms Processor
suitable to a given deployment need, be that fully server-side or fully
client-side.

And the overall final goal of interoperability is to protect the XForms
author from these deployment decisions, and to be able to "late-bind "
those decisions, i.e.  whether you run inside Chiba and are fully
server-side, run inside an XForms-enabled Web browser, or at the
extreme, actually run on a server implementation that delegates part of
the Xforms Processing Model to a client (perhaps via generated
client-side scripts)--- you the XForms author should be protected from
those details.

--Raman 
>>>>> "Jason" == Jason Eacott <jeacott@hardlight.com.au> writes:
    Jason> Thanks Eric, I wasn't arguing that securing an email
    Jason> address wasn't possible at all, just that its not
    Jason> possible with Pure client Xform. After all, you have
    Jason> all those nice Xforms tools available to send emails
    Jason> etc, its a shame not to be able to use them. If you
    Jason> are creating such functionality on the server then for
    Jason> many basic forms you might as well use a plain old
    Jason> html form. seems a waste to me.
    Jason> 
    Jason> 
    Jason> 
    Jason> To: "Flinton Adam" <Adam.Flinton@cfh.nhs.uk>,
    Jason> jeacott@hardlight.com.au Copies to: www-forms@w3.org
    Jason> Subject: Re: AJAX vs. Xforms Date sent: Mon, 07 Nov
    Jason> 2005 08:26:36 -0500 From: "Eric S. Fisher"
    Jason> <efisher@fsystems.com> Organization: WorldSyncPlus,
    Jason> Inc.
    Jason> 
    >> I'm mostly a lurker on this list and am not an active
    >> Xforms developer, but I do know something about the Web
    >> and about security issues; therefore I feel justified in
    >> offering an opinion about server versus client side
    >> security.
    >> 
    >> I agree with Jason that client side applications have
    >> problems keeping secrets.  This is not restricted to
    >> Xforms versions of those applications, however: any "rich
    >> client" will share them.  So, it seems to me, that the
    >> real issue is deciding which "secrets" are safe for the
    >> client side to keep.  To pursue Jason's example, an email
    >> address might indeed be very private, and the application
    >> designer might want to keep all such information inside
    >> the firewall.  In this case I would suggest that the rich
    >> client send a message to a server applet with some sort of
    >> key value that is meaningless outside the context of the
    >> application.  The server side could look up the email
    >> address and send the email.
    >> 
    >> Granted, this is more complicated than a "pure" client
    >> side solution, and I would not suggest it for all
    >> applications.  As always, security is a negotiable issue
    >> subject to cost-benefit analysis, along with every other
    >> aspect of the environment.  We have already dealt with
    >> other rich-client security issues like cookies, and I
    >> don't see this being all that different.
    >> 
    >> Without server support, there are always limitations on
    >> what a client-side application can do.  Where these
    >> limitations can be managed or don't matter, I agree with
    >> Adam that rich clients can be very useful.
    >> 
    >> Eric
    >> 
    >> On Mon, 07 Nov 2005 07:41:55 -0500, Flinton Adam
    >> <Adam.Flinton@cfh.nhs.uk> wrote:
    >> 
    >> >
    >> > Xforms on the client side does make for a very useful
    >> low cost, easy to > implement (assuming the problems I
    >> have detailed are dealt with) way of > rendering a piece
    >> of XML into a human readable/editable form. I accept >
    >> that there are limitations vs. running it against a server
    >> where you can > add in all sorts of nice stuff
    >> e.g. database/datastore access, > authentication etc.etc.
    >> >
    >> > Adam
    >> >
    >> >> -----Original Message----- >> From: Jason Eacott
    >> [mailto:jeacott@hardlight.com.au] >> Sent: 07 November
    >> 2005 11:00 >> To: Flinton Adam >> Cc: www-forms@w3.org >>
    >> Subject: RE: AJAX vs. Xforms
    >> >>
    >> >> > For what it's worth, I don't include Chiba and Orbeon
    >> in >> this class.  >> > Those I haven't used. I think
    >> those projects have problems too, but >> > they're of a
    >> different nature. I'm not convinced of the >> feasibility,
    >> >> > usability, or maintainability of a primarily
    >> server-side >> solution; but >> > that's an argument for
    >> another thread.
    >> >> >
    >> >>
    >> >> I've said this before, >> I'm not convinced of the
    >> feasibility, useability, >> maintainability or security of
    >> clientside solutions.
    >> >>
    >> >> I think clientside Xforms has a serious problem with
    >> keeping secrets.  >> HTML forms are incapable of sending
    >> emails by themselves (and >> many other functions), and
    >> where they require secrets to be >> kept from the client
    >> they need lots of help, usually by means >> of serverside
    >> function.  >> If I want my Xform Submission to send an
    >> email then I have to >> include that/those email
    >> address(es) in the Xform!, If I dont >> then I'd have to
    >> code it as a completely separate serverside >> function
    >> and thats not what Xforms is about. What about a >> case
    >> where I need to send a username and/or password to >>
    >> retreive data from a 3rd party? (perhaps the isp for
    >> example >> holds a subscription to some content service
    >> and it can only >> be accessed by supplying user/pass -
    >> but that information >> should NOT be revealed to the user
    >> of the form.) With a 100% >> clientside implementation I
    >> think this is impossible.  >> With a serverside Xform
    >> implementation at least I can use >> Xforms as it was
    >> intended with all its functionality in tact >> without the
    >> huge security issues potentially associated with >>
    >> sending too much data to the client.  >> This is the
    >> reason I think that the current serverside >>
    >> implementations that people are describing as a stop gap
    >> >> measure until Xforms becomes ubiquitous amongst the big
    >> >> browsers will be around a lot longer than that.
    >> >>
    >> >> its just my opinion, but I think these are big problems
    >> with >> using a 100% clientside solution in many cases. I
    >> can however >> also see cases where having the option to
    >> run clientside >> would be helpful - when the server isnt
    >> available for example.  >> It would be helpful sometimes
    >> to be able to pick and choose >> which parts of a forms
    >> models and views were suitable for >> 100% client only
    >> processing and those which should never be >> used by the
    >> client directly.
    >> >>
    >> >> my 2 cents >> Jason.
    >> >>
    >> >>
    >> >>
    >> >>
    >> >>
    >> >
    >> > This e-mail is confidential and privileged. If you are
    >> not the intended > recipient please accept our apologies;
    >> please do not disclose, copy or > distribute information
    >> in this e-mail or take any action in reliance on > its
    >> contents: to do so is strictly prohibited and may be
    >> unlawful.  > Please inform us that this message has gone
    >> astray before deleting it.  > Thank you for your
    >> co-operation.
    >> >
    >> >
    >> >
    >> 
    >> 
    >> 
    >> -- 
    >> Important Note: This e-mail may contain trade secrets or
    >> privileged, undisclosed or otherwise confidential
    >> information.  If you have received this e-mail in error,
    >> you are hereby notified that any review, copying, or
    >> distribution of it is strictly prohibited.  Please inform
    >> me immediately and destroy the original transmittal.
    >> Thank you for your cooperation.
    Jason>

--
-- T. V. Raman

Received on Tuesday, 8 November 2005 07:32:48 UTC