On 09.02.11 15:45, "Michael Wechner" <[email protected]> wrote:
>On 2/9/11 2:32 PM, Alexander Klimetschek wrote: >> On 09.02.11 15:25, "Carlo Camerino"<[email protected]> wrote: >> >>> is there anyway that I could relate this UUID to the filename? >>> how does jackrabbit compute what file name to fetch based on the UUID >>> attribute ? >> Why do you want to do that? > >I could imagine applying JCR to an existing file system (e.g. SVN layer) > >AFAIK http://jackrabbit.apache.org/jackrabbit-spi.html allows to do >something like this. > >Or do I misunderstand Jackrabbit SPI? AFAIU, SPI is mainly a simpler interface than normal JCR, with batch orientation, to optimize remoting scenarios. For example, a sample usage would be this: jcr2spi spi2webdav <webdav protocol> webdav2jcr (webdav servlet with batch support) and you could more quickly change out the spi2webdav / webdav2jcr part using something else, like spi2myfastprotocol / myfastprotocol2jcr for example. Without SPI, you would always need to implement the full JCR API, jcr2spi saves you that. There is also a spi2jcr to optimize that on the server-side as well, i.e. you'd have a myfastprotocol2spi + spi2jcr on the server. If you want to wrap a different backend and expose it in a JCR-way, you'd need to write the full JCR API. Or you could wrap it under the SPI interface and use jcr2spi on top, to let clients use your wrapper with the JCR API. In this case you would not use jackrabbit-core at all (maybe copy some code ;-)), but mostly use utility stuff from jcr-commons or spi-commons, where large parts of general purpose stuff for implementing the JCR API is located. There is no use of things like Persistence Managers, DataStore etc., because these are meant for implementing a standalone JCR system (even the DB persistence managers only use rdbms to store data in their format, not to map existing relational data, a common misconception). How you handle for example UUIDs (or better, what you expose as UUIDs) is then also a choice of your implementation. Regards, Alex -- Alexander Klimetschek Developer // Adobe (Day) // Berlin - Basel
