Re: svn commit: r925531 - in /sling/trunk/bundles/jcr/resource/src/main: java/org/apache/sling/jcr/resource/ java/org/apache/sling/jcr/resource/internal/ resources/OSGI-INF/metatype/

[Justin Edelson <ju...@gmail.com>]

 Hi-

On Wed, Mar 24, 2010 at 4:17 AM, Carsten Ziegeler <cz...@apache.org>wrote:

> > Author: justin
> > Date: Sat Mar 20 02:22:25 2010
> > New Revision: 925531
> >
> > URL: http://svn.apache.org/viewvc?rev=925531&view=rev
> > Log:
> > SLING-1447 - adding ability to configure multiple workspaces for event
> firing
>
> Hi,
>
> at first I thought that this is a good idea, but rethinking it, I'm not
> sure anymore.
> The problem I see is that if two workspaces contain the same content (or
> partially the same content), then resource events might be fired because
> something changes in workspace x (which is not the default workspace) -
> but event handlers for these events assume that the changes happened in
> the default workspace.
> Resource events have only the path property by default and event handler
> do not expect an additional workspace prop.
>
> I guess first and foremost, the thing I would say is that if you configure
Sling such that it fires events for non-default workspaces, you understand
the consequences of doing so... and that while it is true that the current
set of event handlers do not expect an additional property, this can be
changed where necessary.

I should also say that I had the (faulty) assumption that I would be able to
discuss this multi-workspace stuff face to face with some other Sling devs
at OSGi DevCon [Karl - I enjoyed drinking with you, but this didn't really
seem to be an area of interest :)].


> So I think have to change this, adding the workspace to the path
> property (if it is not the default workspace) would do the trick.
>
Wouldn't this break existing event handlers? If an event handler expects the
path to be a resource/jcr path, and it gets test:/foo/bar (workspace = test,
path = /foo/bar), the event handler will fail.

What might be interesting (haven't yet finished my first cup of coffee
today) is to add a new property to the event which contains a URI, e.g.
resource://test/foo/bar, deprecate the path property, and then migrate event
listeners to rely on this new uri property.

Justin


>
> WDYT?
> Carsten
> --
> Carsten Ziegeler
> cziegeler@apache.org
>

Re: svn commit: r925531 - in /sling/trunk/bundles/jcr/resource/src/main: java/org/apache/sling/jcr/resource/ java/org/apache/sling/jcr/resource/internal/ resources/OSGI-INF/metatype/

[Carsten Ziegeler <cz...@apache.org>]

Carsten Ziegeler  wrote
> Justin Edelson  wrote
> 
>> So are you suggesting that the resource resolver resolve [workspace]:[path]
>> and that Resource.getPath() return this form for non-default workspaces?
> Yes, I'm still not sure what the best way is, but I think it's either
> the above or it's mounting workspaces under specific paths in the
> resource tree. I know that this might create some problems here or
> there, but overall it seems to better fit to the resource tree abstraction.
> I think Sling is more following the Highlander principle: there can only
> be one resource tree. So we have a single (potentially large) resource
> tree. We have users and access rights and can control the visibility
> etc. through these.
> Therefore I'm more in favour of the above solutions.
> 
There might be one problem with having a path like "workspace:path" -
converting this into a url: usually without any mapping the resource is
directly accessible by its resource path, so can use the resource path
to create links without any additional handling.
With a colon in the path this wouldn't work anymore - however, the
correct way to create link is to use the map() method of the resource
resolver. And the resolver could handle this somehow.

Carsten
-- 
Carsten Ziegeler
cziegeler@apache.org

Re: svn commit: r925531 - in /sling/trunk/bundles/jcr/resource/src/main: java/org/apache/sling/jcr/resource/ java/org/apache/sling/jcr/resource/internal/ resources/OSGI-INF/metatype/

[Carsten Ziegeler <cz...@apache.org>]

Justin Edelson  wrote

> So are you suggesting that the resource resolver resolve [workspace]:[path]
> and that Resource.getPath() return this form for non-default workspaces?
Yes, I'm still not sure what the best way is, but I think it's either
the above or it's mounting workspaces under specific paths in the
resource tree. I know that this might create some problems here or
there, but overall it seems to better fit to the resource tree abstraction.
I think Sling is more following the Highlander principle: there can only
be one resource tree. So we have a single (potentially large) resource
tree. We have users and access rights and can control the visibility
etc. through these.
Therefore I'm more in favour of the above solutions.

Carsten
-- 
Carsten Ziegeler
cziegeler@apache.org

Re: svn commit: r925531 - in /sling/trunk/bundles/jcr/resource/src/main: java/org/apache/sling/jcr/resource/ java/org/apache/sling/jcr/resource/internal/ resources/OSGI-INF/metatype/

[Justin Edelson <ju...@gmail.com>]

Sorry it's taken me a few days to get back to this...

On Wed, Mar 24, 2010 at 10:55 AM, Carsten Ziegeler <cz...@apache.org>wrote:

>
> >> So I think have to change this, adding the workspace to the path
> >> property (if it is not the default workspace) would do the trick.
> >>
> > Wouldn't this break existing event handlers? If an event handler expects
> the
> > path to be a resource/jcr path, and it gets test:/foo/bar (workspace =
> test,
> > path = /foo/bar), the event handler will fail.
> No, I don't think this would break existing event handlers (or maybe not
> directly...) - now usually event handlers are interested in changes in
> some areas of the resource tree, like /mycontent etc.
> If the workspace is prefixed with a colon /mycontent does not match
> test:/mycontent and everything is fine.
> The problematic part is, when a event handler puts the path blindly into
> the resource resolver and tries to get the resource, then obviously the
> path could not be resolved - but that might be the same with the special
> workspace property.
>
I was more thinking about cases where one assumed that the first character
in the path is a "/", but now that I think of it, this is probably
less-than-common.

It is worth noting that if you are using workspaces correctly (at least
according to David's Model), then you are likely interested in the same area
of the resource tree in every workspace. This is the case, for example, with
the script resolver (which is where the need to implement cross-workspace
events comes from).


>
> >
> > What might be interesting (haven't yet finished my first cup of coffee
> > today) is to add a new property to the event which contains a URI, e.g.
> > resource://test/foo/bar, deprecate the path property, and then migrate
> event
> > listeners to rely on this new uri property.
>
> Hmm ok, where is the difference between the uri and the path property,
> which means
> where do you put the workspace info in the uri?
>
The difference to me is that URIs tend to be more formalized and it allows
us in this case to make a clean break and not overload an event property
which already has meaning. I could even imagine saying that events from
non-default workspaces don't even have the path property, just the URI
property. I'm thinking resource://[workspace][path] as the syntax (sorry if
this wasn't clear).


> I think path should be sufficient as we are using the path all over the
> place. A Resource.getPath() should return an identical resource when the
> result is put into the resource resolver.
>
So are you suggesting that the resource resolver resolve [workspace]:[path]
and that Resource.getPath() return this form for non-default workspaces?

Justin


>
> Regards
> Carsten
> --
> Carsten Ziegeler
> cziegeler@apache.org
>

Re: svn commit: r925531 - in /sling/trunk/bundles/jcr/resource/src/main: java/org/apache/sling/jcr/resource/ java/org/apache/sling/jcr/resource/internal/ resources/OSGI-INF/metatype/

[Carsten Ziegeler <cz...@apache.org>]

Justin Edelson  wrote
> 
> I should also say that I had the (faulty) assumption that I would be able to
> discuss this multi-workspace stuff face to face with some other Sling devs
> at OSGi DevCon [Karl - I enjoyed drinking with you, but this didn't really
> seem to be an area of interest :)].
Believe me, having a drink with Karl is more interesting than discussing
this stuff with some Sling devs like me:) And yes, I wish I could have
attended the OSGi DevCon :(

>> So I think have to change this, adding the workspace to the path
>> property (if it is not the default workspace) would do the trick.
>>
> Wouldn't this break existing event handlers? If an event handler expects the
> path to be a resource/jcr path, and it gets test:/foo/bar (workspace = test,
> path = /foo/bar), the event handler will fail.
No, I don't think this would break existing event handlers (or maybe not
directly...) - now usually event handlers are interested in changes in
some areas of the resource tree, like /mycontent etc.
If the workspace is prefixed with a colon /mycontent does not match
test:/mycontent and everything is fine.
The problematic part is, when a event handler puts the path blindly into
the resource resolver and tries to get the resource, then obviously the
path could not be resolved - but that might be the same with the special
workspace property.

> 
> What might be interesting (haven't yet finished my first cup of coffee
> today) is to add a new property to the event which contains a URI, e.g.
> resource://test/foo/bar, deprecate the path property, and then migrate event
> listeners to rely on this new uri property.

Hmm ok, where is the difference between the uri and the path property,
which means
where do you put the workspace info in the uri?
I think path should be sufficient as we are using the path all over the
place. A Resource.getPath() should return an identical resource when the
result is put into the resource resolver.

Regards
Carsten
-- 
Carsten Ziegeler
cziegeler@apache.org