You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by Bertrand Delacretaz <bd...@apache.org> on 2008/04/02 12:08:38 UTC
/sling/sling.js path hidden by OSGi management console
Hi,
Working on SLING-351 I noticed that /sling/sling.js is not accessible,
as the OSGi console is mounted on /sling.
I suggest moving that path to /bundles/sling/sling.js, where /bundles
makes it clear that this resource comes from a bundle.
WDYT?
-Bertrand
Re: /sling/sling.js path hidden by OSGi management console
Posted by David Nuescheler <da...@day.com>.
> Ah, now I remember the reason for docroot .... In this case, I would NOT
> put sling.js into docroot. IMHO it is not required to access this
> as /sling.js
i thought so ;) from a "user" perspective though it is hard to explain
and justify a "funky" url. i think this is very similar to the webdav url.
i think the "simplest" case needs to be very simple and i definitely
see value in going out of our way to make the first steps as simple
as possible...
regards,
david
Re: /sling/sling.js path hidden by OSGi management console
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Am Donnerstag, den 03.04.2008, 00:48 -0700 schrieb Tobias Bocanegra:
> > And as you mention sling.js is static, so why not
> >
> > * /system/static/sling.js - the client side library...
> the idea of the docroot is, that it can be remapped to /...so the
> physical location is /system/docrot/sling.js, but is accessible via
> /sling.js, for example. if no such remapping is foreseen for the
> sling.js, then i would put it directly to /system/sling.js.
Ah, now I remember the reason for docroot .... In this case, I would NOT
put sling.js into docroot. IMHO it is not required to access this
as /sling.js
>
> btw: to put files in 'static' just because their are static is a poor
> categorization (as if someone would group all 'html' in one folder and
> all 'js' in another.....(group by function and not by form :-)
Regards
Felix
Re: /sling/sling.js path hidden by OSGi management console
Posted by David Nuescheler <da...@day.com>.
hi guys,
> * /system/sling/console - the sling console
> * /system/sling/info - the info servlet
> * /system/sling/docroot/sling.js - the client side library...
this works out beautifully for me under 1.5 conditions ;)
(1) the docroot mapping works at some point.
which leads to the fact that i can do <script src="/sling.js">.
including (explaining) /system/sling/docroot/sling.js and
therefore exposing the complxity for the most common
case is very painful.
(1.5) we put something meaningful on /system and on /system/sling
i thought quite a lot on where the "system things" should be served up
from and i guess everybody knows that i am the "stick everything
into the repository" guy. never the less i initially i thought these kind
of system functions should be served up from some magic bundle...
then i thought we could have a "sling system ws" that we sort of magically
mount into /system/sling ... but in the end i think that there might well be
workspaces that are "slinged" and others that are not within the same
repository.
so i am happy populating the /system/sling folder of every "slinged"
workspace in a repository.
regards,
david
On Thu, Apr 3, 2008 at 9:48 AM, Tobias Bocanegra
<to...@day.com> wrote:
> > And as you mention sling.js is static, so why not
> >
> > * /system/static/sling.js - the client side library...
> the idea of the docroot is, that it can be remapped to /...so the
> physical location is /system/docrot/sling.js, but is accessible via
> /sling.js, for example. if no such remapping is foreseen for the
> sling.js, then i would put it directly to /system/sling.js.
>
> btw: to put files in 'static' just because their are static is a poor
> categorization (as if someone would group all 'html' in one folder and
> all 'js' in another.....(group by function and not by form :-)
>
> regards, toby
>
Re: /sling/sling.js path hidden by OSGi management console
Posted by Tobias Bocanegra <to...@day.com>.
> And as you mention sling.js is static, so why not
>
> * /system/static/sling.js - the client side library...
the idea of the docroot is, that it can be remapped to /...so the
physical location is /system/docrot/sling.js, but is accessible via
/sling.js, for example. if no such remapping is foreseen for the
sling.js, then i would put it directly to /system/sling.js.
btw: to put files in 'static' just because their are static is a poor
categorization (as if someone would group all 'html' in one folder and
all 'js' in another.....(group by function and not by form :-)
regards, toby
Re: /sling/sling.js path hidden by OSGi management console
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Thu, Apr 3, 2008 at 10:02 AM, David Nuescheler <da...@day.com> wrote:
> > > And as you mention sling.js is static, so why not
> > > * /system/static/sling.js - the client side library...
> > > to make it explicit.
> why would that be interesting to a user?
> static is not a property of that script include that bears any meaning
> to the user....
You and all others are correct ;-)
I was mixing this up with the fact that resources served by bundles
are nowhere to be found in the repository, which might be confusing -
but as mentioned in my other message, putting those resources under
/system is a first step towards making that easier to explain:
whatever's under /system usually comes from bundles, not from the
repository.
-Bertrand
Re: /sling/sling.js path hidden by OSGi management console
Posted by David Nuescheler <da...@day.com>.
> > And as you mention sling.js is static, so why not
> > * /system/static/sling.js - the client side library...
> > to make it explicit.
why would that be interesting to a user?
static is not a property of that script include that bears any meaning
to the user....
regards,
david
Re: /sling/sling.js path hidden by OSGi management console
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Am Donnerstag, den 03.04.2008, 12:00 +0200 schrieb Alexander
Klimetschek:
> Am 03.04.2008 um 10:06 schrieb Bertrand Delacretaz:
> >
> > My larger concern is that those resources, served by bundles, are not
> > discoverable. What I love when working with a JCR repository (like on
> > a unixish system) is that everything is very visible and hackable, in
> > files and folders - and we lose this for those "magic" resources
> > served by bundles.
>
> ACK.
>
> > We don't need to address this right now, but as David mentions in this
> > thread there should be a way to "see" those bundle resources along
> > with what's stored in the repository.
>
> _wish mode on_
JIRA is your friend here ;-)
>
> There was once the idea of a resource browser built into sling.
> Haven't looked at Sling's trunk for a while - has it been done?
I once had a prototype for testing ... but I think I lost it over
deleting repositories --- this is the drawback of storing code in the
repo ;-)
>
> _now christmas + easter together_
>
> It could be a general place for displaying all kinds of magic
> redirects, docroot mappings, servlet filters and whatever. Maybe also
> a kind of simulator or debugger that shows the resolving for a given
> URL.
Sounds all very reasonable. Why don't you go create JIRAs for these ? I
am sure, one day there will be fixes for some.
Some things of course already exist:
* magic redirects : There is a configuration page for this
* docroot mappings: Same here
* Servlet Filters: not visible direclty, but in the configuration
status you filter services
* ...
Agreed that this all requires some intimate knowledge and some kind of
consolidation would certainly make sense.
For example, Servlet Filters are expected to be reflected in the
Resource Tree - which would allow scripted filters - as per SLING-199
such that they may be visible in the resource tree browser.
Regards
Felix
Re: /sling/sling.js path hidden by OSGi management console
Posted by Alexander Klimetschek <ak...@day.com>.
Am 03.04.2008 um 10:06 schrieb Bertrand Delacretaz:
>
> My larger concern is that those resources, served by bundles, are not
> discoverable. What I love when working with a JCR repository (like on
> a unixish system) is that everything is very visible and hackable, in
> files and folders - and we lose this for those "magic" resources
> served by bundles.
ACK.
> We don't need to address this right now, but as David mentions in this
> thread there should be a way to "see" those bundle resources along
> with what's stored in the repository.
_wish mode on_
There was once the idea of a resource browser built into sling.
Haven't looked at Sling's trunk for a while - has it been done?
_now christmas + easter together_
It could be a general place for displaying all kinds of magic
redirects, docroot mappings, servlet filters and whatever. Maybe also
a kind of simulator or debugger that shows the resolving for a given
URL.
_wish mode off_
Just my 2 eurocents.... ;-)
Alex
--
Alexander Klimetschek
alexander.klimetschek@day.com
Re: /sling/sling.js path hidden by OSGi management console
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Thu, Apr 3, 2008 at 9:57 AM, Felix Meschberger <fm...@gmail.com> wrote:
> ... (with the exception regarding the "static" path, we can really place
> that at /system/sling.js)...
Agree with that, or docroot with mapping to /sling.js, I'm ok with both.
> >... 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....
My larger concern is that those resources, served by bundles, are not
discoverable. What I love when working with a JCR repository (like on
a unixish system) is that everything is very visible and hackable, in
files and folders - and we lose this for those "magic" resources
served by bundles.
We don't need to address this right now, but as David mentions in this
thread there should be a way to "see" those bundle resources along
with what's stored in the repository.
For now (or soon after our first release), making sure that all
resources served by bundles are under /system might be a good idea, if
we want to make that a virtual path later, that is visible (but
read-only) in the repository - like the /proc filesystem on linux.
-Bertrand
Re: /sling/sling.js path hidden by OSGi management console
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Am Donnerstag, den 03.04.2008, 09:34 +0200 schrieb Bertrand Delacretaz:
> On Thu, Apr 3, 2008 at 8:49 AM, Felix Meschberger <fm...@gmail.com> 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
Re: /sling/sling.js path hidden by OSGi management console
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Thu, Apr 3, 2008 at 8:49 AM, Felix Meschberger <fm...@gmail.com> 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.
All this needs to be discoverable, so I'd make sure /system returns an
HTML document with links to the above items.
This doesn't prevent us from adding more system stuff later, for
example /system/jmx could be used later for management stuff.
> ...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.
-Bertrand
Re: /sling/sling.js path hidden by OSGi management console
Posted by Tobias Bocanegra <to...@day.com>.
> * /system/sling/console - the sling console
> * /system/sling/info - the info servlet
> * /system/sling/docroot/sling.js - the client side library
ok.
> 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.
but only Fridays :-)
Re: /sling/sling.js path hidden by OSGi management console
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Am Donnerstag, den 03.04.2008, 08:39 +0200 schrieb Bertrand Delacretaz:
> On Wed, Apr 2, 2008 at 7:34 PM, Tobias Bocanegra
> <to...@day.com> wrote:
> > what about putting the sling console to some other place? eg:
> >
> > /slingconsole
> > /system/sling/console ?
>
> Agreed, but maybe /system/console to make it a bit shorter?
Actually a good idea ;-) The original path /sling stems from the times
where did not yet have a good clue of how to place things..
>
> >
> > we should avoid 'cluttering' the root context as much as possible.
> > furthermore, i wold move the sling.js to /libs/sling/docroot/sling.js
>
> Note that sling.js is served directly from its bundle, not from the
> repository. I'd suggest /system/libs/sling.js, so that only the
> /system root path is reserved for stuff provided by
> Catapult^H^H^H^H^H^H^H Sling.
I agree completely that we should put it into /system instead of /libs.
But we should try to consolidate a bit. We have - besides the standard
servlets in a relative path, the following absolute paths (taking
Bertrands proposals into account):
* /system/console - the sling console
* /system/libs/sling.js - the client side library
* /system/sling/info - the sling info servlet
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
WDYT ?
Regards
Felix
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.
>
> -Bertrand
Re: /sling/sling.js path hidden by OSGi management console
Posted by Bertrand Delacretaz <bd...@apache.org>.
On Wed, Apr 2, 2008 at 7:34 PM, Tobias Bocanegra
<to...@day.com> wrote:
> what about putting the sling console to some other place? eg:
>
> /slingconsole
> /system/sling/console ?
Agreed, but maybe /system/console to make it a bit shorter?
>
> we should avoid 'cluttering' the root context as much as possible.
> furthermore, i wold move the sling.js to /libs/sling/docroot/sling.js
Note that sling.js is served directly from its bundle, not from the
repository. I'd suggest /system/libs/sling.js, so that only the
/system root path is reserved for stuff provided by
Catapult^H^H^H^H^H^H^H Sling.
-Bertrand
Re: /sling/sling.js path hidden by OSGi management console
Posted by Tobias Bocanegra <to...@day.com>.
what about putting the sling console to some other place? eg:
/slingconsole
/system/sling/console ?
we should avoid 'cluttering' the root context as much as possible.
furthermore, i wold move the sling.js to /libs/sling/docroot/sling.js
regards, toby
On 4/2/08, Felix Meschberger <fm...@gmail.com> wrote:
> Hi,
>
> Am Mittwoch, den 02.04.2008, 12:08 +0200 schrieb Bertrand Delacretaz:
>
> > Hi,
> >
> > Working on SLING-351 I noticed that /sling/sling.js is not accessible,
> > as the OSGi console is mounted on /sling.
> >
> > I suggest moving that path to /bundles/sling/sling.js, where /bundles
> > makes it clear that this resource comes from a bundle.
> >
> > WDYT?
>
>
> We have the info servlet at /system/sling/info. How about placing the
> sling.js at /system/sling/sling.js ?
>
> Regards
>
> Felix
>
>
Re: /sling/sling.js path hidden by OSGi management console
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Am Mittwoch, den 02.04.2008, 12:08 +0200 schrieb Bertrand Delacretaz:
> Hi,
>
> Working on SLING-351 I noticed that /sling/sling.js is not accessible,
> as the OSGi console is mounted on /sling.
>
> I suggest moving that path to /bundles/sling/sling.js, where /bundles
> makes it clear that this resource comes from a bundle.
>
> WDYT?
We have the info servlet at /system/sling/info. How about placing the
sling.js at /system/sling/sling.js ?
Regards
Felix
Re: /sling/sling.js path hidden by OSGi management console
Posted by Bertrand Delacretaz <bd...@apache.org>.
Hi,
On Wed, Apr 2, 2008 at 1:10 PM, Carsten Ziegeler <cz...@apache.org> wrote:
> Bertrand Delacretaz wrote:
> > ...I suggest moving that path to /bundles/sling/sling.js, where /bundles
> > makes it clear that this resource comes from a bundle....
> ... Hmm, I'm not sure :) - I think it shouldn't be of interest for the client
> to know where the js comes from (bundle vs repository)....
It can be of interesting for people who wonder where that file comes
from, as most of the other requests can be traced to repository nodes.
Not sure if /bundles is a good choice, but having a path convention
for things that (by default) are served from bundles would help people
find out what is what. Maybe /static/sling-client/sling.js ?
> ... Furthermore I think we should move the js to a different bundle...
Agree with that, sling-client maybe? That could also contain the test
page that is currently under launchpad/content.
-Bertrand
Re: /sling/sling.js path hidden by OSGi management console
Posted by Carsten Ziegeler <cz...@apache.org>.
Bertrand Delacretaz wrote:
> Hi,
>
> Working on SLING-351 I noticed that /sling/sling.js is not accessible,
> as the OSGi console is mounted on /sling.
>
> I suggest moving that path to /bundles/sling/sling.js, where /bundles
> makes it clear that this resource comes from a bundle.
>
> WDYT?
>
Hmm, I'm not sure :) - I think it shouldn't be of interest for the
client to know where the js comes from (bundle vs repository).
But I don't have any good suggestion for a better path yet.
Furthermore I think we should move the js to a different bundle. The
post servlets are of general use (with or without the script). I could
imagine that over time, the js lib might evolve while the post servlets
do not. With shipping the js together with the post servlets we create a
contract we can't break later on.
Carsten
--
Carsten Ziegeler
cziegeler@apache.org