JackRabbit code review '05

Przeglądając wiki Alfresco natrafiłem na archiwalny raport z audytu kodu Apache JackRabbit'a. Opis dotyczy wersji 0.16.2 z okolic 2005 roku - wtedy w fazie inkubacji. Panowie zastanawiają się nad użyciem implementacji Apache w architekturze powstającego ECM Alfresco. Poniżej ciekawsze fragmenty.

Andy (Hind ?):

• No version control
• Persistence is not synchronised and will have threading issues

• Not sure if they have workspaces> (There is no system workspace and noy dynamic workspace. I think there is just one * workspace) - Could support this in subversion style
• There can be multiple instantiations pointing at the same repository which will cause havoc.
• Does authentication and authorization work – looks very simple …

David (Caruana ?):

In the bug tracking system, the following comment may back this up - "i must admit that i took no care about multihtreading until now. but of course i will do it now." - a comment from the guy who wrote the versioning piece.

When you look at the code, you get the Slide v1.0 feeling. There are going to be bugs due to the amount of in-memory data structures that need to be kept just right - in a multi-threaded context. It's not the sort of thing that's easily fixed - there will be a Slide 3.0 equivalent when a re-design of the architecture is considered.

Given all this caching, hierarchy related processing performance will still suffer. There's no indexing as far as I can see.

As Andy has pointed out, there are numerous holes and inconsistencies - I expect these will get fixed as time goes by.

What do we do with JackRabbit?

We could:
1. Use it as our basic Repository capability - build our stuff around it
2. Build our own Repository capability and use JackRabbit where possible to provide a JSR-170 facade
3. Not use it at all

Option 1 might be viable if it's a stepping stone to building a community quickly with the intention of replacing it.

But, my preference is option 2. We'd probably gut JackRabbit anyway (not very nice!!) to cater for native db implementation and subversion type capability and also to fix reliability issues. However, it would give a head-start to providing a facade to our own stuff e.g. Type Model, Query etc.

Pełna wersja raportu.