Hi, Am Donnerstag, den 03.04.2008, 09:34 +0200 schrieb Bertrand Delacretaz: > On Thu, Apr 3, 2008 at 8:49 AM, Felix Meschberger <[EMAIL PROTECTED]> wrote: > > > ...Now, this is a bit scattered. Given that the console and info are both > > servlets, we should place them in the same location. I would also not do > > the "libs" path in /system but trying to signal that sling.js actually > > is a static, we could do > > > > * /system/sling/console - the sling console > > * /system/sling/info - the info servlet > > * /system/sling/docroot/sling.js - the client side library... > > IMHO the /sling bit could go away, our "system" is sling anyway, so I'd > suggest > > * /system/console - the sling console > * /system/info - the info servlet > > And as you mention sling.js is static, so why not > > * /system/static/sling.js - the client side library... > > to make it explicit.
+1 (with the exception regarding the "static" path, we can really place that at /system/sling.js) > > All this needs to be discoverable, so I'd make sure /system returns an > HTML document with links to the above items. Not sure ;-) But adding such a thing does certainly not hurt. > > This doesn't prevent us from adding more system stuff later, for > example /system/jmx could be used later for management stuff. Yes, makes sense. > > > ...BTW: Whether it is served directly from the bundle or from the > > repository is IMHO secondary and of no big importance to the casual > > user.... > > Yes, but that's still reserving some URI space for Sling's purposes - > if the console servlet was mounted at /content, for example, that > would prevent people from putting stuff in their repository under that > path. This is mostly of importance for the console whose URL is not resolve through sling but by the HttpService. For other URLs, in particular servlets, this is not this dramatic. Regards Felix
