Re: [Off-Topic] Property level security
> Finally, as noted before, if you do have use cases which fetch a lot of > different nodes (or better say: in all cases) your repository will be much > faster if you use a "local" persistence manager with no network connection > and no roundtrips. Yep, fine for the dev environment but in the prod environment we'll most likely use MySQL to benefit from the existing clustering structure. Regards, Markus
Re: Sling+ModeShape
Alexander Klimetschek wrote > > I agree, and I don't propose to take the resource API away. All I am > saying is that it should be kept read-only. > Ok, let's agree that we disagree wrt to CRUD and Sling :) Especially as the resource api already provides the update function - so basically missing is just create and delete; while delete is easy, create is the more difficult operation. Regards Carsten -- Carsten Ziegeler cziege...@apache.org
Re: [Off-Topic] Property level security
On 17.01.11 15:42, "Markus Joschko" wrote:
>Does jackrabbit really make a request per next() call on the children
>iterator or does it optimize and fetches all children (as long as the
>number is reasonable low) when retrieving the iterator?
For getNodes() it uses a LazyItemIterator that fetches only on next(). In
your use case you will probably rather use getNode("childnode"), where you
fetch node by node (since your application will most probably know what
the child nodes are).
But when talking about a few child nodes that won't make any difference at
all.
Finally, as noted before, if you do have use cases which fetch a lot of
different nodes (or better say: in all cases) your repository will be much
faster if you use a "local" persistence manager with no network connection
and no roundtrips.
Regards,
Alex
--
Alexander Klimetschek
Developer // Adobe (Day) // Berlin - Basel
Re: Sling+ModeShape
On 17.01.11 16:00, "Carsten Ziegeler" wrote: >And with Sling's resource API you get an even simpler API on top of it :) > >At one point in time, we'll be able to do CRUD through the resource api, >it's not much left to do there anyway and this will allow to write >complete applications just based on the resource api. And developers >will benefit from all the Sling features - In contrast to JCR which is >an API, Sling is a framework with the aim to make developers live easier. Yes, but we are talking specifically about the Sling Resource API here. And so far that has been geared towards a read-only, small and efficient API, that is easy to use. Which it implemented perfectly. However, I strongly expect that adding write operations in the API will make it "too" complex. Especially because then you open a whole new set of wishes from all sides, which in the end will not give you a good API, I think. >I see a lot of benefits, use cases and scenarios where the current >available (open source ) implementations are lacking functionality. In >addition, I have use cases where I want to run Sling without a >repository underneath or with several different repository mount at >different locations in the resource tree. >Just think about how easy it is to mount a file directory or resources >from within a bundle into the resource tree - this works today. Of >course this is doable from within a repository, but especially when I >think about OSGi resources it seems like the wrong approach :) I agree, and I don't propose to take the resource API away. All I am saying is that it should be kept read-only. Regards, Alex -- Alexander Klimetschek Developer // Adobe (Day) // Berlin - Basel
Re: Sling+ModeShape
Alexander Klimetschek wrote > On 14.01.11 22:33, "Carl Hall" wrote: >> >> On Fri, Jan 14, 2011 at 2:47 AM, Carsten Ziegeler >> wrote: >>> We have more features on our list for the resource resolver >>> (factory/provider) which would allow to create, update and delete >>> resources as well (I think there is a wiki page regarding this). So if >>> you need something in this area, maybe it's now a good time to address >>> these things >> >> The resource resolver and resource provider have been invaluable to us. >> The >> resource layer in general has made our work much easier. > > Please note that the current value of the resource API over the JCR API is > only that it is simpler, thus more quickly to implement with some custom > backend. If more and more is added to the Resource API, especially all the > complexities of write operations, this value will be completely lost, and > I would urge everyone doing so to implement the needed subset of the JCR > API instead. > > Federation/virtual mounting (which is another useful feature of the > resource API) can also be done with the JCR API as modeshape shows or > something that we have in our proprietary CRX repository here at Adobe/Day. > > It all just boils down to the development effort... but with JCR you get a > well-though out standard. > And with Sling's resource API you get an even simpler API on top of it :) At one point in time, we'll be able to do CRUD through the resource api, it's not much left to do there anyway and this will allow to write complete applications just based on the resource api. And developers will benefit from all the Sling features - In contrast to JCR which is an API, Sling is a framework with the aim to make developers live easier. I see a lot of benefits, use cases and scenarios where the current available (open source ) implementations are lacking functionality. In addition, I have use cases where I want to run Sling without a repository underneath or with several different repository mount at different locations in the resource tree. Just think about how easy it is to mount a file directory or resources from within a bundle into the resource tree - this works today. Of course this is doable from within a repository, but especially when I think about OSGi resources it seems like the wrong approach :) I don't see the Sling API competing with the JCR API - as I said, Sling is framework :) Regards Carsten -- Carsten Ziegeler cziege...@apache.org
Re: [Off-Topic] Property level security
> Also, the nodes are cached in Jackrabbit in-memory, so if you have > repeated read-only access to those nodes, there will be no need to fetch > them from the persistence manager again. Does jackrabbit really make a request per next() call on the children iterator or does it optimize and fetches all children (as long as the number is reasonable low) when retrieving the iterator? > > But you touch a good point: generally it is good to have a higher property > per node ratio - something like 5-10 properties per node. With 4 nodes per > request however, it should still be fine! > > Regards, > Alex > > -- > Alexander Klimetschek > Developer // Adobe (Day) // Berlin - Basel > > > > >
Re: Sling+ModeShape
On 14.01.11 22:33, "Carl Hall" wrote: > >On Fri, Jan 14, 2011 at 2:47 AM, Carsten Ziegeler >wrote: >>We have more features on our list for the resource resolver >> (factory/provider) which would allow to create, update and delete >> resources as well (I think there is a wiki page regarding this). So if >> you need something in this area, maybe it's now a good time to address >> these things > >The resource resolver and resource provider have been invaluable to us. >The >resource layer in general has made our work much easier. Please note that the current value of the resource API over the JCR API is only that it is simpler, thus more quickly to implement with some custom backend. If more and more is added to the Resource API, especially all the complexities of write operations, this value will be completely lost, and I would urge everyone doing so to implement the needed subset of the JCR API instead. Federation/virtual mounting (which is another useful feature of the resource API) can also be done with the JCR API as modeshape shows or something that we have in our proprietary CRX repository here at Adobe/Day. It all just boils down to the development effort... but with JCR you get a well-though out standard. Just my 2 cents, Alex -- Alexander Klimetschek Developer // Adobe (Day) // Berlin - Basel
Re: [Off-Topic] Property level security
On 13.01.11 08:25, "Markus Joschko" wrote: >I thought more in the direction of node traversal. Instead of loading >just one node and checking ACLs I have to load the parent node and >three childnodes to get a complete view. I have no idea how node >retrieval is implemented in jackrabbit but given there is a database >behind I fear that I have four db requests (parent+3 children) reads >instead of one to create my view. This depends on the persistence manager. The bundle DB persistence manager will do that (one bundle per node), but if you use e.g. the embedded Derby or H2 persistence managers, you don't have network latency. Also, the nodes are cached in Jackrabbit in-memory, so if you have repeated read-only access to those nodes, there will be no need to fetch them from the persistence manager again. But you touch a good point: generally it is good to have a higher property per node ratio - something like 5-10 properties per node. With 4 nodes per request however, it should still be fine! Regards, Alex -- Alexander Klimetschek Developer // Adobe (Day) // Berlin - Basel
