Hi guys, > I agree, that we might want to wait for a real-life request. > On the other hand it is not only the end-users fault if not the correct > methods could be used, though browsers are probably the major number of > culprits. Many times it is just a question of firewall limitation which > can by no means be circumvented by the casual user on the internet ... I agree, aswell.
Generally, I guess what I would be excited to use from a microsling user perspective is: (a) a flexible and very easily extensible GET that does all my different renditions of a content node on the server (b) a clean PUT and DELETE that operates as expected, which is probably triggered through some XHR based js lib in the browser. (c) a functionally powerful POST that (amongst other things) allows me to trigger any content repository modification through a straight html-form in a browser. Generally, this means that as a user I am less interested in tweaking the "writing" mechanisms to the repository, since they are sufficiently simple and complete, while the rendering/presentation is very user and usecase specific. I would personally stay away from any of the mentioned "HTTP method simulation" techniques (until requested). Personally I would assume that there are requirements such as dealing versioning operations or batching up multiple modifications that (short of implementing WebDAV and its ugly cousins) would go into the "powerful" ootb POST handling. Personally I could see a powerful POST handling to be very similar to what Bertrand and I use in http://www.day.com/maven/rjax/ Thoughts? regards, david
