You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lenya.apache.org by Felix Röthenbacher <fe...@wyona.com> on 2005/08/17 12:24:56 UTC
Re: [RFO] [1.4] JCR-only vs. Repository Abstraction Layer
I strongly agree with Andreas to focus on JCR only!
Andreas mentioned many good reasons for focusing on
JCR only. One point I want to stress once more is
that focusing on JCR will disburden the Lenya community
from maintaining a repository on its own. Additionally,
versioning, locking, transaction, etc. is also
mostly covered and taken care of by JCR.
BR,
Felix
Andreas Hartmann wrote:
> Hi Lenya devs,
>
> we have to come to a decision about the repository question.
> People stated their opinions, it looks like there are two
> general directions.
>
> If you think it's too early for a vote, please request cancelling.
>
> Vote:
>
> (a) Lenya should focus on JCR only. It is OK to implement core
> functionality which absolutely relies on JCR features.
>
> +1
>
> ----
>
> (b) Lenya should support other repository implementations as well,
> without implementing custom JCR content repositories.
> This means we need a Lenya-specific repository abstraction layer.
>
> ----
>
> (c) That should be deferred, let's release 1.4 with the current
> repository implementation. I'm aware that this could imply
> bigger migration efforts from 1.4 to 1.6.
>
>
> Some advantages of (a):
>
> - We can leverage the full power of JCR.
>
> - We don't have to care about designing another repo layer (which is quite
> complex).
>
> - We don't have to care about compliance between several repo
> implementations.
>
> - We don't have to mimic JCR functionality in other repo implementations.
>
> - Testing efforts are reduced. (we don't have automated tests yet, that's
> not good but it is the truth and we have to face it)
>
> - Overall: faster, cleaner, simpler.
>
>
> Some advantages of (b):
>
> - Assuming that the Lenya repo API is not as complex as JCR, it is
> easier to implement back-ends (content repositories, e.g. SVN-backed).
>
> - We don't rely on external code.
>
> - Overall: more flexible, more independent.
>
>
> ----
>
> A note about doco etc.:
>
> There will always be the need for other repositories.
> But IMO we should differentiate between
>
> - using a repo as a Lenya repository and
> - allowing to export / import content to / from a repo
>
> In the case of doco, IIUC there's no need for using the SVN versioning
> for CMS versioning, is there? Maybe an (automated) export to an SVN
> repository would be sufficient.
>
> -- Andreas
>
>
--
Felix Röthenbacher felix.roethenbacher@wyona.com
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [RFO] [1.4] JCR-only vs. Repository Abstraction Layer
Posted by Torsten Schlabach <ts...@apache.org>.
Wolfgang,
> BTW: Jackrabbit's default storage -is- the filesystem. Question to
> those
> who have experimented with it thus far: how does it do this, e.g. one
> big file, or one file per "item", or one per "node" and one per
> "property", ... ? I suppose we probably should not rely on that anyway
> (e.g. for automated svn functionality), but I am still curious :)
The good news is: It is not one big file. I wouldn't actually consider
this "filesystem" then but rather "binary". This would be probably what
you get when using the BerkeleyDB backend that I thought I read
something about.
You cannot tell exactly if this is one file per node and one file per
property, but what I can tell for sure:
In the workspaces/data folder of a filesystem repository you will find a
lot of folders with names in hex values that contain other folders with
names in hex values which at some point contain XML files with properties.
In other words: Folders and filenames are entirely unrelated to the
outside view of the repository, which in my opinion renders them useless
for any other purpose but reading and writing the content through
Jackrabbit. (I guess that was the question behind your question.)
Don't forget the basic idea of UUID in JCR. JCR is *not primarily* a
tree structure with folders and files. You can model it that way if you
want, but you can also build entirely different systems of reference. I
think (haven't tried) you can even have parallel systems of referencing
the same content.
Hope this helps.
Regards,
Torsten
J. Wolfgang Kaltz schrieb:
>> Andreas Hartmann wrote:
>>
>>> Hi Lenya devs,
>>>
>>> we have to come to a decision about the repository question.
>>> People stated their opinions, it looks like there are two
>>> general directions.
>>>
>>> If you think it's too early for a vote, please request cancelling.
>>>
>>> Vote:
>>>
>>> (a) Lenya should focus on JCR only. It is OK to implement core
>>> functionality which absolutely relies on JCR features.
>>>
>>> +1
>
>
> Assuming this decision is neutral regarding the question "will Lenya be
> used for Apache doco", I'm also
> +1
>
> BTW: Jackrabbit's default storage -is- the filesystem. Question to those
> who have experimented with it thus far: how does it do this, e.g. one
> big file, or one file per "item", or one per "node" and one per
> "property", ... ? I suppose we probably should not rely on that anyway
> (e.g. for automated svn functionality), but I am still curious :)
>
>
> --
> Wolfgang
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
> For additional commands, e-mail: dev-help@lenya.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [RFO] [1.4] JCR-only vs. Repository Abstraction Layer
Posted by "J. Wolfgang Kaltz" <ka...@interactivesystems.info>.
> Andreas Hartmann wrote:
>
>> Hi Lenya devs,
>>
>> we have to come to a decision about the repository question.
>> People stated their opinions, it looks like there are two
>> general directions.
>>
>> If you think it's too early for a vote, please request cancelling.
>>
>> Vote:
>>
>> (a) Lenya should focus on JCR only. It is OK to implement core
>> functionality which absolutely relies on JCR features.
>>
>> +1
Assuming this decision is neutral regarding the question "will Lenya be
used for Apache doco", I'm also
+1
BTW: Jackrabbit's default storage -is- the filesystem. Question to those
who have experimented with it thus far: how does it do this, e.g. one
big file, or one file per "item", or one per "node" and one per
"property", ... ? I suppose we probably should not rely on that anyway
(e.g. for automated svn functionality), but I am still curious :)
--
Wolfgang
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org