Hi guys, I agree that I would really like to keep things as simple as possible.
Therefore I think that a GET to the exact repository path should generally be handled the same way as the WebDAV GET. I think this is very easy to understand for everybody and means that microsling generally works just like every other WebDAV enabled webserver for everything that is static. In addition to that we allow "url decoration" such as selectors and extensions, these are handled by microsling in its more advanced request processing and mapping. Personally, I think that this is a very simple and straightforward solution that leverages a lot of features implemented in WebDAV entirely correctly. Think of etag or modified since behaviour on GET or PUT and DELETE which all would have to be re-implemented in microsling. Generally I think WebDAV is very Restful and a very good basis to start and sort of decorate microsling on top of a webdav enabled server. I think there are no collisions or special cases, I would generally say that if someone addresses an item directly with what i would call an "exact path match", the WebDAV behaviour by default is an excellent choice. I think assuming assuming that people add an extension to let's say /content/mypage when GETting /content/mypage.html though microsling is good practice anyway. regards, david On 10/19/07, Felix Meschberger <[EMAIL PROTECTED]> wrote: > Am Freitag, den 19.10.2007, 11:42 +0200 schrieb Bertrand Delacretaz: > > On 10/19/07, Felix Meschberger <[EMAIL PROTECTED]> wrote: > > > > > ...I would > > > say, that we should not mix microsling/Sling generation and WebDAV > > > generation as it will never correctly workout, unfortunately.... > > > > Why wouldn't that work? > > Because a WebDAV GET is not the same as a microsling/Sling GET in the > general case. > > > I agree that mixing WebDAV and other protocols in the same URL space > > might not work depending on what the other protocols are, but what > > could go wrong in the simple microsling case? > > Just having to explain: A request is passed through Sling Servlet > resolutions unless the RequestURL exactly matches the JCR resource in > which case the request is handled as if it were a WebDAV request ... > This calls for nasty problems and hard to explain special cases. > > > > > I'm curious mostly, I cannot argue 100% that it would work, so if you > > have contrary evidence it'd help me figure out the issues. > > > > Having a full WebDAV implementation (the Jackrabbit one I assume) > > *plus* our cool resource resolving and scripting stuff in the same URI > > space sounds like a big benefit for microsling...there might be > > downsides, but I'd prefer us to analyze them before dismissing the > > idea. > > With the exception that it does not work. We (Day) tried this in other > products (Communiqué for concrete) and always came to the conclusion, > that we have to clearly separate WebDAV from the rest. So in Communiqué > we solved the issue of just prefixing WebDAV requests such that > http://host/dav/xxx/yyy would be a WebDAV request to resource /xxx/yyy > while http://host/xxx/yyy would be the "normal" request to > resource /xxx/yyy. > > And as always: Keeping things simple means: Don't create special > cases ... > > Regards > Felix > >
