On 18/02/2008, Manolo Gomez Lopez <[EMAIL PROTECTED]> wrote: > 2008/2/18, Stefan Guggisberg <[EMAIL PROTECTED]>: > > > > > > >while i agree it could be very convenient in certain scenarios i guess > > >it can cause > > >a lot of trouble (how do you handle removed types, illegal > > >definitions, unsupported > > >changes etc) if supported in core during bootstrapping. while editing > > >a text based > > >definition is certainly trivial, the effects of such changes might be > > dramatic. > > > > >OTOH i think such a feature could be easily implemented as an external > > >tool/service. > > >WDYT? > > > > cheers > > stefan > > > > > > > > Greets, > > > > > > > > Yeah, sure, maybe an external tool will be a good idea, but it won't be > trivial, it should support the three different models of accessing a > jackrabbit repository, direct, JNDI, RMI... and a way of declaring > namespaces, or at least guessing them from the provided CND files. > > I see that the API approach is well suited for the first two models of > deployment, where the application code and jackrabbit reside in the same > location (context). But I think it doesn't fully fit in the RMI scenario > where there maybe exists a repository administrator and several clients > without administrative rights, if one wants to control the types of nodes in > the system. > > Maybe I am extending too far the current RMI interface and making jackrabbit > more service than planned... which leads me to the following: Is there > any ongoing effort for providing a web services or some sort of remote > interface ( SOAP, RPC, REST ) to JCR repositories and jackrabbit in > particular? > >
I think that the Apache Abdera project has done some work in terms of exposing an AtomPub interface to a JCR repository, using jackrabbit as the underlying implementation. I'm not sure how complete it is, or how well it would meet your requirement though. Cheers, James
