> >or we should start thinking of a jackrabbit-api. that would contain > >also those classes. > > > >however: > >- what is the general feeling about this? > > > > > I see no reason for a Jackrabbit API except perhaps regarding the > NodeType Management stuff, which would be nice if it would be available > in a way that for example the RMI layer could also provide those without > relying on core Jackrabbit.
i think a public jackrabbit API beyond jsr-170 would be a very healthy and good thing, see http://incubator.apache.org/jackrabbit/arch/overview.html i think this goes beyond nodetype management, it is really all the functions that have been removed from the jcr api but we have a general consensus that it a repository has to implement them in one form or another. this includes obviously things like nodetype mgmt, workspace mgmt, access control but possibly also things like synchronous observation, or parameters on stored queries. those could all be candidates for inclusion in future versions of the general jcr api. generally, i think we should express somehow which jackrabbit specific features a "jackrabbit application developer" should use. currently this is not clearly visible in the jackrabbit java doc, since there are a variety of reasons to make something "public". regards, david
