- From: Noah Mendelsohn <nrm@arcanedomain.com>
- Date: Mon, 02 Jun 2014 10:55:02 -0400
- To: Larry Masinter <masinter@adobe.com>, Alex Russell <slightlyoff@google.com>
- CC: "www-tag@w3.org" <www-tag@w3.org>, "Robin Berjon (robin@w3.org)" <robin@w3.org>
I think I agree with much of Larry's analysis but not his conclusion. Yes: having multiple encoding standards for the same function in the system results in additional platform code, complexity, testing burden, etc. However, as Larry says: > As far as developers go – Yes, it would be really nice if you could just > call JSON.parse of the HTTP POST Indeed. And that may result in simplification of client- and/or server-code for a very large number of applications. There's a lot of JSON data floating around and being able to send/receive it without conversion is in many cases a significant simplification. This is arguably a significant net benefit even if there is some regrettable duplication of function in the middleware layers. Noah On 6/1/2014 4:41 PM, Larry Masinter wrote: > Let me try again. > > Right now, we have two ways of encoding form data, x-urlencoded and > multipart/form-data. > > It is unlikely that the requirement to implement BOTH encodings, both in > browsers and also in web servers. > > Sites that expect one or both of those will remain common, so browsers will > always need the code to generate. > > And browsers that send x-urlencoded or multipart/form-data even when asked > for JSON will also take > > a long time to go away, so web servers will continue to have to implement > decoding of both methods of form data. > > Adding a third way of encoding forms for transmission over the internet – > no matter how nice > > it would have been if we’d done it in the first place – this new way > doesn’t decrease the complexity > > of the platform. I know multipart/form-data is verbose but it’s what we have. > > As far as developers go – Yes, it would be really nice if you could just > call JSON.parse of the HTTP POST > > body, instead of some ugly multipart/form-data parser, but no real > implementation can get away > > from having the parser for the ugly stuff too. > > ØCan you cite specific technical issues which you believe are higher > priority and a rubric for why that's true? > > Maybe there’s some idea that later someone might be able to come up with a > transition plan where mulitpart/form-data and x-urlencoded will go away, > and JSON form data will become universal. and this is a first step on that > plan, but even then, most of the issues in the multipart/form-data document > STILL need to be resolved, with or without JSON form data; encoding of > non-ASCII file names; determining document charset and its effect on form > data submission > > Øcomplexity isn't already being borne by many in the form of pervasive > library code > > Complexity of implementations != complexity of platform. > > When the interface is complicated, it FORCES the implementations to be > complicated. > > Ø“blessing /any/ encoding without describing the mechanism by which it > works is anti-extensibility and therefore robs all users of power and > generality” > > I really don’t know what that means or how it applies here. Can you > explain? I’m not talking about blessing anything, just about fixing what > we have. > > Larry > > -- > > http://larry.masinter.net > > *From:*Alex Russell [mailto:slightlyoff@google.com] > *Sent:* Friday, May 30, 2014 3:18 PM > *To:* Larry Masinter > *Cc:* www-tag@w3.org; Robin Berjon (robin@w3.org) > *Subject:* Re: HTML JSON form data > > Hi Larry, > > Can you cite specific technical issues which you believe are higher > priority and a rubric for why that's true? Or can you cite data to suggest > that this complexity isn't already being borne by many in the form of > pervasive library code (e.g., I know we had a dojo.formToJson() method for > nearly identical functionality because it was so commonly requested and > Form serialization is welded-shut in the platform). > > If anything, it seems the technical argument here should be that blessing > /any/ encoding without describing the mechanism by which it works is > anti-extensibility and therefore robs all users of power and generality. > > Regards > > On Fri, May 30, 2014 at 12:06 AM, Larry Masinter <masinter@adobe.com > <mailto:masinter@adobe.com>> wrote: > > This is a good example of adding new features without paying attention > to fixing what’s already there in need of clean up. > > The result is an even more complex platform and more unreliability, not > less. > > *From:* Larry Masinter > *Sent:* Thursday, May 29, 2014 11:25 PM > *To:* 'public-html@w3.org <mailto:public-html@w3.org>' > *Subject:* Re: Extension specification proposal: JSON form submission > > Although form submission in JSON might have been nicer than what we > have, I see no prospect of ever getting rid of either x-url-encoded or > mulipart/form-data. Before you put a lot of effort into adding > something new that will just add to complexity and implementation > burden, could you please give some serious attention to the > mulipart/form-data spec? > > https://github.com/masinter/multipart-form-data > > Including test framework. Review, update, pull requests. > > Larry > > -- > > http://larry.masinter.net >
Received on Monday, 2 June 2014 14:55:29 UTC