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 01:21:01 UTC