On Tue, 2004-04-13 at 19:37, Gianugo Rabellino wrote:
> Rolf Kulemann wrote:
>
> > Lenya needs a kind of repository to base on.
> > AFAICS, there are the following possibilities for the Lenya community:
> >
> > - WebDAV using apaches webdavlib directly, which is not that bad, imho
> > since all our requirements are more or less met, but is not that
> > "highlevel" as jsr170.
>
> Well, it's orthogonal: WebDAV is a protool, and you're looking for an
> API/object model.
Yes ok, but I could image to use i.e. WebdavResource to access arbitrary
WebDAV repositories. Why not. It will work. Of course we would not rely
on a "standard API" but it seems to be hard to find one.
>
> > - Using Slide direct, which can not propose since Lenya will be bound to
> > Slide repositry only
>
> Not to mention that you will be limited to in memory Slide, which takes
> most of the beauty of having a repository away (think scalability).
Yes.
>
> > - Use one of Cocoon's "various" repository blocks, which, to be honest,
> > are not useable, since they "all" seem to be incomplete in our sense. i
> > tested the "new" repository interface and the WebDAV impl. and it seems
> > quite ok, but it lacks searching support. And as I see this is a "barrel
> > without bottom".
>
> Well, this is your opinion, which I don't quite share: it's pretty clear
> to some of us that searching, by itself, doesn't belong to the
> repository itself. I still don't see why don't you start thinking about
> extending the current repository by adding a (separate) search layer on
> top of it.
Because, I do not think that such a solution will scale. If a repository
(i.e. slide or other webdav reps.) does not support searching, I would
agree with u.
I also agree with u, that we might need some "helpers", instead of
blowing up the repository interface. BUT imho those helpers also belong
more or less to the repository interface. IMHO the helper impls. decide
if they delegate searching direct the backend (i.e. using SearchMethod
from org.apache.webdav.**) or doing a "selfmade" not very scaling search
on simple property queries. "It is like doing a join in a nested loop"
instead of using sql, imho.
>
>
> > - Use jsr170, which at the mom makes most sense to me in theory. I would
> > need to play with the a reference impl. or so in order to see "how it
> > feels like"
>
> Even so, keep in mind that what you'll see is a first public review, not
> a release. API will be shaky for a while and, again, ou might end up
> being tied to a single repository implementation (Slide with the JCRRI).
> Which, TBH, looks more than fair enough to me.
Ok, but Cocoons repository interface(s) are shaky, too.
>
> > To summarize:
> >
> > We need to decide to rely on WebDAV or JSR170. At the mom cocoon's rep.
> > interface are not meeting the requirements the lenya people have, imho.
>
> IMHO, you're mixing concerns: my take is that you could use Cocoon's
> repos _plus_ your favourite search layer on top of it.
Again, it is an interesting idea I will take into account, thanks
AGAIN:
I would very much appreciate to have some search helpers and appropriate
classes/interfaces to support search. I know that is maybe difficult.
If this is not possible in the next time, I will try do my own search
helpers even if they are bound i.e. to WebDAV only first. Maybe they
become good enough for
RepositorySearchHelper and
WebDAVRepositorySearchHelper
Makes sense?
--
Regards,
Rolf Kulemann
