jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Nuescheler <david.nuesche...@gmail.com>
Subject Re: spec and levels
Date Fri, 14 Jan 2005 09:32:40 GMT
hi guys,

thanks a lot for all the comments.
as the spec-lead of jsr-170 i obviously feel responsible for 
the rationale behind the current split-up into levels
and maybe i can shed some light on that and give
you guys some historical background.

first of all it is important to understand that jsr-170
is not only an api for brandnew repositories like
jackrabbit but also to a great extent has its 
motivation in the ability and feasibilty to connect
to existing proprietary repositories.

so while i completely agree with gianugos
statement about having a read-only repository
being questionable, it may just be what many 
(simple) applications need.
reading from an existing repository that is 
written through a proprietary (or obscure) 
mechanism, and display the information
amy just be good enough for many 

to give you some examples, let's assume that
you have your existing document management
system or your ldap-server, which is managed
through its proprietary mechanisms, now if you
are in the position where you need to query and
display information out of those repositories 
level one compliancy is going to be just what 
you need. on the other side, it is going to be 
very easy to supply a level one compliant 
connector for those repositories which will
drive adoption.

so the main drivers behind making level
one read-only was:
a) make it simple:
avoid the complexity of the transient space, 
for a repository that wants to expose its content
to jsr-170 (implementing the transient space is
a substancial overhead)

b) keep it useful for many usecases:
still cover as many usecases as possible.
even in our (day software's) complete 
enterprise cms product, where we make use of
all the advanced functionalities that jsr-170 
has to offer, i would argue that ~97% of the
code is dealing with level one calls. of course
because of other ~3% (small but important) 
code our product we will have to rely on
a fully jsr-170 compliant repository to offer
all of its functionality.
with respect to most custom-built code like
display portlets or website templates in many
situations it is not necessary to go beyond 
what level one has to offer. 

so the guiding principle was to get as much 
"bang for the buck" as possible. basically, we
asked ourselves, how simple can we make it 
and still cover most usecases.

personally, i am in favour of those changes
and i think they are for the better. the 
transient space is hard to implement and 
i think adoption will suffer if we unnecessarily 
burden repository vendors with implementing
the full transient space for level one.

as roy pointed out, there will be (very, very many) 
simple repository applications (templates, 
portlets, reports, ...) that operate nicely on level 
one but obviously there will be (much fewer) 
advanced applications which will rely on level two
or even the advanced features of the spec.

i will try to write up some of this and put some
charts together, and put it into the xdocs.


View raw message