on 6/18/03 3:16 AM Ugo Cei wrote: > Gianugo Rabellino wrote: > >>>Anyway, I'm wondering why the multipart request. Is it because of >>>images? If it weren't for images, wouldn't it be better to POST a >>>text/xml body with all the necessary information, putting the "verb" >>>(save, delete, etc.) in the URI, in the style of REST? >> >>Probably so. And if we need multipart to achieve such a *huge* usability >>boost, I'm all for using it! :-) > > > Me too, even though I'd love to have the Linotype backend as a > REST-style Web Service. In my vision, the editor should just POST an XML > document, using some well-known schema (say RSS, augmented with Dublin > Core for metadata) instead of an ad-hoc namespace like > "http://www.betaversion.org/linotype/news/1.0";.
Hey, wait a second. The ad-hoc namespace is added as a wrapper by the request processing pipeline, it is *NOT* sent by the client code. > Can we have this > together with transparent upload of images? Well, I don't know, but I > think I'm going to look into the code in a few minutes. The browsers don't give you access to <input type="file"> content from javascript, it is considered a security issue by most browsers, so there is no way you can bypass the form-encoding capabilities of the browser and, say, encode images as CDATA in a big XML payload, forget it. So, if you upload files from a browser, you have to use multipart-form encoding. period. What you can do is to encode your data as an XML file and send that, but I really don't see the value of doing this instead of just POSTing a bunch of parameters (which is as REST-ish as anything I can think of) >>BTW, Stefano: Linotype *really* kicks ass. Problem is that from you we >>aren't expecting anything less, so this is why you are not getting all >>the kudos you deserve. :-) But it's really, really, really a good job! > > > Ditto. Thanks. -- Stefano.
