Am Freitag, den 19.10.2007, 15:36 +0200 schrieb Tobias Bocanegra:
> > > I do not think, that this is a good idea. It involves magic and leaves
> > > the microsling context in a way we cannot and most probably will not
> > > support in Sling and thus creates an incompatibility.
> > >
> > > Rather I would suggest to implement a SpoolServlet (extends
> > > SlingSafeMethodsServlet) which handles nt:file requests
> > > (MicroSlingServlet.addServlet("nt:file", new SpoolServlet()) and just
> > > pumps out the nt:file (or the Property value to which the
> > > Node.getPrimaryItem() trail leads).
> >
> > i agree with felix that having a spool servlet is a better option.
> > nevertheless, i would provide a webdav servlet with the default setup.
> > so that users can easily upload/manager their static content in the
> > repository.
>
> i rethought about this. the current webdav servlet in jackrabbit is
> pretty cool and feature complete. especially for GET requests it
> suports etags, if-last-modified-since, etc. and it would silly to
> reimplement this again.
I completely agree with you and will not dispute this :-)
> furthermore, i think for the other methods (PUT, DELETE, MKCOL) etc
> the webdav servlet provides the good defaults.
Same here ...
> so i suggest to drop
> the StreamServlet idea, and map all exact-match resources per default
> to the webdav servlet.
But not here. The WebDAV servlet is great and provides a number of
useful features for what it is called DAV, namely Authoring.
But, let us now take the other route: How would you implement this in
microsling ?
I have in mind a solution, where the MicroSlingServlet will try to
resolve the resource and check for any selectors, extension and suffix.
If none of these exist, the MicroSlingServlet would delegate to the
WebDAV servlet, right ?
How would this be done ? By RequestDispatcher.include or by a 301/302 ?
However it is done, the MicroSlingServlet must have knowledge of the
WebDAV servlet !
So we have to big issues here: (1) we create a special case (no
extension, selectors, suffix) and (2) we create a dependency to another
servlet in microsling.
Both may be disputed over. But IMHO this construct violates one thing:
Simplicity. Probably it even violates the "separation of concerns"
principle.
Therefore, we should keep the StreamServlet (it is simple and lean and
shows another concept of microsling, namely Servlet selection by
resource type) and just go with it for what it is intended to do.
Regards
Felix
