W3C home > Mailing lists > Public > uri@w3.org > November 2008

Re: [rest-discuss] RE: [whatwg] Proposing URI Templates for WebForms 2.0

From: Subbu Allamaraju <subbu@subbu.org>
Date: Sat, 1 Nov 2008 10:56:04 -0700
Cc: Mike Schinkel <mikeschinkel@gmail.com>, "'Mark Nottingham'" <mnot@mnot.net>, "'Ian Hickson'" <ian@hixie.ch>, "'Jerome Louvel'" <contact@noelios.com>, whatwg@lists.whatwg.org, uri@w3.org, rest-discuss@yahoogroups.com
Message-Id: <18871997-C2DF-4138-A83A-7A4E3CD9FE81@subbu.org>
To: Erik Wilde <dret@berkeley.edu>

On Nov 1, 2008, at 10:01 AM, Erik Wilde wrote:

> Subbu Allamaraju wrote:
>> I see the use cases, but what is the server gaining with this  
>> flexibility? In other words, how many servers out there are going  
>> to benefit from this technique?
> the question is more how many page authors will be able to reliably  
> develop forms against services/servers? i think mike's idea is  
> pretty good because it increases loose coupling between clients and  
> servers.

I don't disagree, and I do see the value of templates for non-browser  
scenarios. But the most of the web today won't be taking advantage of  
this for a long time.

> on today's web, forms and services are more or less tightly coupled,  
> and they almost are developed as one thing. mike proposes an  
> architecture that introduces a more loose coupling, because a form  
> is able to interact with more services than before.

Again, I don't disagree about loose-coupling, but the technique serves  
just a tiny tiny fraction. Also consider the amount of JS code out  
there that knows how to construct URIs from form params and other  
inputs. That won't be migrating to use templates anytime soon.

> ( mike, please correct me if i am wrong. )
>> Not having templates in forms does not violate URI opacity since  
>> HTML forms do follow a well-defined and well-understood approach to  
>> construct a URI from form parameters.
> yes, but if you have some service out there that expect certain  
> URIs, then currently it is not possible to build a form for that,  
> unless the service does expect form-encoded data. mike's proposal  
> would allow forms to interact with a much wider set of services.

Same as above. Those services/servers can very well allow form-encoded  
data. I would argue that, doing so is better since it would let them  
work with existing browsers and JS libraries.

Received on Saturday, 1 November 2008 17:56:42 UTC

This archive was generated by hypermail 2.4.0 : Sunday, 10 October 2021 22:17:51 UTC