You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lenya.apache.org by Andreas Hartmann <an...@apache.org> on 2006/06/07 11:20:34 UTC
Human-readable UUIDs, languages in UUIDs [was: let's go! [was: Outside
Perspective on 1.2 vs 1.4 divergent efforts]]
Michael Wechner wrote:
[...]
>>>> does this imply moving to flat storage,
>>>
>>> well, it could be anything, whatever your "persistance manager" would
>>> do ;-) but the important thing is that they
>>> would never need to be changed ...
>>
>> IMO it would imply flat storage (from an API point of view, the internal
>> storage could be a B-Tree or something like that for performance
>> reasons). The persistence layer shouldn't have to care about URL space
>> or site structure issues, otherwise SoC / software orthogonality would
>> be violated.
>
> agreed. I just wanted to point out that it doesn't have to be flat and
> it could
> still be human readable depending how we want to implement it.
Yes, I see.
From my point of view, the repository layer knows only about UUIDs.
If we want to allow human-readable storage, that would mean that
the UUIDs have to be human-readable. When a document is created, the
user would enter an (optional?) UUID string (if it is omitted, the
system chooses one).
----
Another question: How should languages be handled? Some options:
1. The repository layer knows about languages (i.e., a storage item
is identified by a combination of UUID and language).
2. The repository layer UUID is a combination of CMS UUID and
language (e.g., news + de -> news_de).
3. UUIDs and languages are not combined, i.e. every translation
is identified by its own UUID or the language is part of the UUID.
This would either lead to redundance (if the language is stored
in the meta data additionally) or convention regarding the syntax
of the UUID, so that language queries can be done.
IMO option (1) is the most reasonable, I see no need for abstracting
from the language in the repository layer.
WDYT?
-- Andreas
--
Andreas Hartmann
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
andreas.hartmann@wyona.com andreas@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Human-readable UUIDs, languages in UUIDs [was: let's go! [was: Outside Perspective on 1.2 vs 1.4 divergent efforts]]
Posted by so...@apache.org.
On 6/7/06, Andreas Hartmann <an...@apache.org> wrote:
> solprovider@apache.org wrote:
> > On 6/7/06, Andreas Hartmann <an...@apache.org> wrote:
> >> Another question: How should languages be handled? Some options:
> >> 1. The repository layer knows about languages (i.e., a storage item
> >> is identified by a combination of UUID and language).
> >>
> >> 2. The repository layer UUID is a combination of CMS UUID and
> >> language (e.g., news + de -> news_de).
> >>
> >> 3. UUIDs and languages are not combined, i.e. every translation
> >> is identified by its own UUID or the language is part of the UUID.
> >> This would either lead to redundance (if the language is stored
> >> in the meta data additionally) or convention regarding the syntax
> >> of the UUID, so that language queries can be done.
> >>
> >> IMO option (1) is the most reasonable, I see no need for abstracting
> >> from the language in the repository layer.
> >
> > Lenya is language-aware. #2 and #3 make that very difficult because
> > different sitetrees are needed for each language.
>
> Hmm, I don't understand this implication ...
> In all three cases, the sitetree would return a UUID for a given URL.
> The difference is only about how the framework accesses the repository
> layer, isn't it?
>
> > While Lenya1.3
> > makes that possible (you can have as many structures as you want, and
> > they could be language-specific), it makes the expected case of the
> > same structure for all languages very difficult.
> >
> > #1 is already implemented. Resources have Translations.
>
> That would also be the case with (2) and (3). It's just about internal
> storage, the API wouldn't be affected. Or am I missing something?
If each Resource has only one language (using either #2 or #3), each
language must maintain separate structures (more work, more code, more
bugs), and some possibilities of having multiple and default
Translations disappear.
Start with:
UNID=0021(DefaultLanguage="en")/Translation(Language="en")/contentfile
Every request uses "en".
Now add Translation(Language="de").
German uses "de"; all others use "en".
More importantly, no changes to Structures, XSL, or Documents were
required. If the visitor uses "de", the "de" Translation is used. If
the "de" Translation is deleted, it defaults back to "en".
The SitetreeGenerator builds the sitetree from the Resources that
exist for the current language, or have a defaultLanguage that exists.
Since the example "0021" has a defaultLanguage, it would exist in the
sitetree for all languages.
There could also be:
UNID=0022(No Default Language)
/Translation(Language="en")
/Translation(Language="de")
Only the English and German sitetrees would contain this Resource (and
its children if using a Structure). The moment
Translation(Language="ru") is created/published, the Resource would
appear in Russian sitetrees, without updating structures.
This also affects graphics. Setting the default language for the
homepagetitle.gif to "en" shows a graphic like "My Company". Add an
"ru" Translation, and Russians see their own graphic. That could be
important when certain colors or symbols have negative connotations in
certain countries.
solprovider
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Human-readable UUIDs, languages in UUIDs [was: let's go! [was:
Outside Perspective on 1.2 vs 1.4 divergent efforts]]
Posted by Michael Wechner <mi...@wyona.com>.
Michael Wechner wrote:
> Andreas Hartmann wrote:
>> solprovider@apache.org wrote:
>>> On 6/7/06, Andreas Hartmann <an...@apache.org> wrote:
>>>> From my point of view, the repository layer knows only about UUIDs.
>>>> If we want to allow human-readable storage, that would mean that
>>>> the UUIDs have to be human-readable. When a document is created, the
>>>> user would enter an (optional?) UUID string (if it is omitted, the
>>>> system chooses one).
>>>
>>> http://en.wikipedia.org/wiki/UUID
>>> UUIDs are 16-byte numbers. Titles are human-readable. In Lenya1.3,
>>> the unique key to each Resource is referred to as a UNID (Unique
>>> Identifier). A UNID can be any String acceptable as a directory name.
>>
>> Thanks for clarifying this!
>
> btw, there is an implementation of UUIDs
>
> <dependency groupId="apache-jakarta-commons"
> artifactId="apache-jakarta-commons-discovery"
> version="0.2"/>
> <dependency groupId="apache-jakarta-commons"
> artifactId="apache-jakarta-commons-id"
> version="0.1-dev-lcr357257"/>
> <dependency groupId="apache-jakarta-commons"
> artifactId="apache-jakarta-commons-logging"
> version="1.0.4"/>
btw, we can pull in these libs by using Maven Ant Tasks
http://maven.apache.org/ant-tasks.html
which work very well ;-)
Michi
>
> whereas Java 1.5 is supporting UUID out of the box IIRC.
>
> Having said that I wasn't refereing to UUID as it may defined, but
> rather as identifiers which are unique within Lenya
> and hence could be human readable without provoking a conflict, but I
> think the above is also fine.
>
> Michi
>
--
Michael Wechner
Wyona - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
michael.wechner@wyona.com michi@apache.org
+41 44 272 91 61
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Human-readable UUIDs, languages in UUIDs [was: let's go! [was:
Outside Perspective on 1.2 vs 1.4 divergent efforts]]
Posted by Michael Wechner <mi...@wyona.com>.
Andreas Hartmann wrote:
> solprovider@apache.org wrote:
>> On 6/7/06, Andreas Hartmann <an...@apache.org> wrote:
>>> From my point of view, the repository layer knows only about UUIDs.
>>> If we want to allow human-readable storage, that would mean that
>>> the UUIDs have to be human-readable. When a document is created, the
>>> user would enter an (optional?) UUID string (if it is omitted, the
>>> system chooses one).
>>
>> http://en.wikipedia.org/wiki/UUID
>> UUIDs are 16-byte numbers. Titles are human-readable. In Lenya1.3,
>> the unique key to each Resource is referred to as a UNID (Unique
>> Identifier). A UNID can be any String acceptable as a directory name.
>
> Thanks for clarifying this!
btw, there is an implementation of UUIDs
<dependency groupId="apache-jakarta-commons"
artifactId="apache-jakarta-commons-discovery"
version="0.2"/>
<dependency groupId="apache-jakarta-commons"
artifactId="apache-jakarta-commons-id"
version="0.1-dev-lcr357257"/>
<dependency groupId="apache-jakarta-commons"
artifactId="apache-jakarta-commons-logging"
version="1.0.4"/>
whereas Java 1.5 is supporting UUID out of the box IIRC.
Having said that I wasn't refereing to UUID as it may defined, but
rather as identifiers which are unique within Lenya
and hence could be human readable without provoking a conflict, but I
think the above is also fine.
Michi
--
Michael Wechner
Wyona - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
michael.wechner@wyona.com michi@apache.org
+41 44 272 91 61
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Human-readable UUIDs, languages in UUIDs [was: let's go! [was:
Outside Perspective on 1.2 vs 1.4 divergent efforts]]
Posted by Andreas Hartmann <an...@apache.org>.
solprovider@apache.org wrote:
> On 6/7/06, Andreas Hartmann <an...@apache.org> wrote:
>> From my point of view, the repository layer knows only about UUIDs.
>> If we want to allow human-readable storage, that would mean that
>> the UUIDs have to be human-readable. When a document is created, the
>> user would enter an (optional?) UUID string (if it is omitted, the
>> system chooses one).
>
> http://en.wikipedia.org/wiki/UUID
> UUIDs are 16-byte numbers. Titles are human-readable. In Lenya1.3,
> the unique key to each Resource is referred to as a UNID (Unique
> Identifier). A UNID can be any String acceptable as a directory name.
Thanks for clarifying this!
> The current implementation uses "0001", "0002", etc., but there is no
> reason not to use UUIDs in the future.
With UUIDs, the file names wouldn't be human readable, given that the
repository implementation uses one file per document and that files
are identified by their UUIDs. This is fine with me, since it's an
internal storage detail - what do the others think?
>> ----
>> Another question: How should languages be handled? Some options:
>> 1. The repository layer knows about languages (i.e., a storage item
>> is identified by a combination of UUID and language).
>>
>> 2. The repository layer UUID is a combination of CMS UUID and
>> language (e.g., news + de -> news_de).
>>
>> 3. UUIDs and languages are not combined, i.e. every translation
>> is identified by its own UUID or the language is part of the UUID.
>> This would either lead to redundance (if the language is stored
>> in the meta data additionally) or convention regarding the syntax
>> of the UUID, so that language queries can be done.
>>
>> IMO option (1) is the most reasonable, I see no need for abstracting
>> from the language in the repository layer.
>
> Lenya is language-aware. #2 and #3 make that very difficult because
> different sitetrees are needed for each language.
Hmm, I don't understand this implication ...
In all three cases, the sitetree would return a UUID for a given URL.
The difference is only about how the framework accesses the repository
layer, isn't it?
> While Lenya1.3
> makes that possible (you can have as many structures as you want, and
> they could be language-specific), it makes the expected case of the
> same structure for all languages very difficult.
>
> #1 is already implemented. Resources have Translations.
That would also be the case with (2) and (3). It's just about internal
storage, the API wouldn't be affected. Or am I missing something?
-- Andreas
--
Andreas Hartmann
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
andreas.hartmann@wyona.com andreas@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: Human-readable UUIDs, languages in UUIDs [was: let's go! [was: Outside Perspective on 1.2 vs 1.4 divergent efforts]]
Posted by so...@apache.org.
On 6/7/06, Andreas Hartmann <an...@apache.org> wrote:
> From my point of view, the repository layer knows only about UUIDs.
> If we want to allow human-readable storage, that would mean that
> the UUIDs have to be human-readable. When a document is created, the
> user would enter an (optional?) UUID string (if it is omitted, the
> system chooses one).
http://en.wikipedia.org/wiki/UUID
UUIDs are 16-byte numbers. Titles are human-readable. In Lenya1.3,
the unique key to each Resource is referred to as a UNID (Unique
Identifier). A UNID can be any String acceptable as a directory name.
The current implementation uses "0001", "0002", etc., but there is no
reason not to use UUIDs in the future.
> ----
> Another question: How should languages be handled? Some options:
> 1. The repository layer knows about languages (i.e., a storage item
> is identified by a combination of UUID and language).
>
> 2. The repository layer UUID is a combination of CMS UUID and
> language (e.g., news + de -> news_de).
>
> 3. UUIDs and languages are not combined, i.e. every translation
> is identified by its own UUID or the language is part of the UUID.
> This would either lead to redundance (if the language is stored
> in the meta data additionally) or convention regarding the syntax
> of the UUID, so that language queries can be done.
>
> IMO option (1) is the most reasonable, I see no need for abstracting
> from the language in the repository layer.
Lenya is language-aware. #2 and #3 make that very difficult because
different sitetrees are needed for each language. While Lenya1.3
makes that possible (you can have as many structures as you want, and
they could be language-specific), it makes the expected case of the
same structure for all languages very difficult.
#1 is already implemented. Resources have Translations. Some
Resources (such as a language-independent graphic) have a
"defaultlanguage" for when no Translation exists for the current
language.
solprovider
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [1.4] UUIDs in persistence layer
Posted by Michael Wechner <mi...@wyona.com>.
Andreas Hartmann wrote:
> Michael Wechner wrote:
>
> [...]
>
>> well, in order to show what I think how it should be implemented I
>> have started
>> something at http://svn.wyona.com/repos/public/yanel/trunk
>>
>> whereas it's not quite working yet and also got distracted on
>> versioned published interfaces ... I have done this because I am
>> afraid I will never be able to explain my ideas, so I will try to let
>> this code speak.
>
> BTW, if you consider these ideas valuable for 1.4, IMO it would be
> nice if you could post a summary so that the community gets an
> overview without examining the code. WDYT?
sure. Will try to do this shortly. For the moment one could say it's
from an architecture POV about
- versioned published interfaces (although Java doesn't provide this I
think one can implement it as a workaround)
(the idea is it will always be backward compatible and also forward
compatibly as good as it can)
- request2process mapping whereas a process is defined by a resource type
- seperation of "request" navigation from repository navigation
Thanks
MIchi
>
> -- Andreas
>
--
Michael Wechner
Wyona - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
michael.wechner@wyona.com michi@apache.org
+41 44 272 91 61
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [1.4] UUIDs in persistence layer
Posted by Andreas Hartmann <an...@apache.org>.
Michael Wechner wrote:
[...]
> well, in order to show what I think how it should be implemented I have
> started
> something at http://svn.wyona.com/repos/public/yanel/trunk
>
> whereas it's not quite working yet and also got distracted on versioned
> published interfaces ... I have done this because I am afraid I will
> never be able to explain my ideas, so I will try to let this code speak.
BTW, if you consider these ideas valuable for 1.4, IMO it would be
nice if you could post a summary so that the community gets an
overview without examining the code. WDYT?
-- Andreas
--
Andreas Hartmann
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
andreas.hartmann@wyona.com andreas@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [1.4] UUIDs in persistence layer
Posted by Andreas Hartmann <an...@apache.org>.
Michael Wechner wrote:
> Andreas Hartmann wrote:
>> Michael Wechner wrote:
>>> Andreas Hartmann wrote:
>>>
>>>> Hi Lenya devs,
>>>>
>>>> to sum up the recent UUID discussion:
>>>>
>>>> From my point of view, the next step would be to use UUIDs to
>>>> identify documents. That would mean that the default persistence
>>>> mechanism would store documents in a flat structure which would
>>>> look like this:
>>>>
>>>>
>>>> 550e8400-e29b-11d4-a716-446655440000
>>>> 550e8400-e29b-11d4-a716-446655440000.meta
>>>
>>>
>>> is 550e8400-e29b-11d4-a716-446655440000 (without suffix meta) the
>>> actual content? I guess you are refering to the reference to the
>>> resource,
>>> right?
>>
>> It would be the name of the file which contains the actual content.
>
> I think this is exactly the problem, that a URL doesn't have to
> correspond to exactly one resource
> within a repository, be it referenced by UUID or whatever and I think
> this is what we need to
> change within Lenya
But how is this issue related with the actual content storage?
The mapping from URLs to resources isn't subject of this thread,
or am I getting this wrong?
>>>> 550e8400-e29b-11d4-a716-446655440231
>>>> 550e8400-e29b-11d4-a716-446655440231.meta
>>>> 550e8400-e29b-11d4-a716-446655443402
>>>> 550e8400-e29b-11d4-a716-446655443402.meta
>>>>
>>>>
>>>> Do you share this opinion?
>>>
>>>
>>> if we are talking about a default persistance manager then yes, but
>>> if this would be hardcoded, then no ;-)
>>
>> The question is if the persistence manager should get any
>> information apart from the UUID. If only the UUID is provided,
>> there won't be a chance to use human-readable file names.
>
> right, IIRC this is what Jackrabbit does and I think it's wrong, whereas
> it might be good
> practice, but I think one should give people the freedom to make also
> use of the path
But if you pass information which is a concern of a certain layer
to the layers below, you lose the advantages of the layered architecture ...
>>>> If not, how do you envision the storage structure?
>>>
>>>
>>> I am not sure if we are confusing actual storage with referencing?
>>>
>>> well, in order to show what I think how it should be implemented I
>>> have started
>>> something at http://svn.wyona.com/repos/public/yanel/trunk
>>>
>>> whereas it's not quite working yet and also got distracted on
>>> versioned published interfaces ... I have done this because I am
>>> afraid I will never be able to explain my ideas, so I will try to let
>>> this code speak.
>>
>> OK, I'll take a look at it as soon as I find the time.
>
> no problem. I didn't mean the actual code, but rather the ideas
> illustrated by this code :-)
OK, so I hope I get the ideas by reading the code :)
-- Andreas
--
Andreas Hartmann
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
andreas.hartmann@wyona.com andreas@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [1.4] UUIDs in persistence layer
Posted by Michael Wechner <mi...@wyona.com>.
Andreas Hartmann wrote:
> Michael Wechner wrote:
>> Andreas Hartmann wrote:
>>
>>> Hi Lenya devs,
>>>
>>> to sum up the recent UUID discussion:
>>>
>>> From my point of view, the next step would be to use UUIDs to
>>> identify documents. That would mean that the default persistence
>>> mechanism would store documents in a flat structure which would
>>> look like this:
>>>
>>>
>>> 550e8400-e29b-11d4-a716-446655440000
>>> 550e8400-e29b-11d4-a716-446655440000.meta
>>
>>
>> is 550e8400-e29b-11d4-a716-446655440000 (without suffix meta) the
>> actual content? I guess you are refering to the reference to the
>> resource,
>> right?
>
> It would be the name of the file which contains the actual content.
I think this is exactly the problem, that a URL doesn't have to
correspond to exactly one resource
within a repository, be it referenced by UUID or whatever and I think
this is what we need to
change within Lenya
>
>
>>> 550e8400-e29b-11d4-a716-446655440231
>>> 550e8400-e29b-11d4-a716-446655440231.meta
>>> 550e8400-e29b-11d4-a716-446655443402
>>> 550e8400-e29b-11d4-a716-446655443402.meta
>>>
>>>
>>> Do you share this opinion?
>>
>>
>> if we are talking about a default persistance manager then yes, but
>> if this would be hardcoded, then no ;-)
>
> The question is if the persistence manager should get any
> information apart from the UUID. If only the UUID is provided,
> there won't be a chance to use human-readable file names.
right, IIRC this is what Jackrabbit does and I think it's wrong, whereas
it might be good
practice, but I think one should give people the freedom to make also
use of the path
>
>
>>> If not, how do you envision the storage structure?
>>
>>
>> I am not sure if we are confusing actual storage with referencing?
>>
>> well, in order to show what I think how it should be implemented I
>> have started
>> something at http://svn.wyona.com/repos/public/yanel/trunk
>>
>> whereas it's not quite working yet and also got distracted on
>> versioned published interfaces ... I have done this because I am
>> afraid I will never be able to explain my ideas, so I will try to let
>> this code speak.
>
> OK, I'll take a look at it as soon as I find the time.
no problem. I didn't mean the actual code, but rather the ideas
illustrated by this code :-)
Thanks
Michi
>
> Thanks for your reply,
>
> -- Andreas
>
>
--
Michael Wechner
Wyona - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
michael.wechner@wyona.com michi@apache.org
+41 44 272 91 61
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [1.4] UUIDs in persistence layer
Posted by Andreas Hartmann <an...@apache.org>.
Michael Wechner wrote:
> Andreas Hartmann wrote:
>
>> Hi Lenya devs,
>>
>> to sum up the recent UUID discussion:
>>
>> From my point of view, the next step would be to use UUIDs to
>> identify documents. That would mean that the default persistence
>> mechanism would store documents in a flat structure which would
>> look like this:
>>
>>
>> 550e8400-e29b-11d4-a716-446655440000
>> 550e8400-e29b-11d4-a716-446655440000.meta
>
>
> is 550e8400-e29b-11d4-a716-446655440000 (without suffix meta) the
> actual content? I guess you are refering to the reference to the resource,
> right?
It would be the name of the file which contains the actual content.
>> 550e8400-e29b-11d4-a716-446655440231
>> 550e8400-e29b-11d4-a716-446655440231.meta
>> 550e8400-e29b-11d4-a716-446655443402
>> 550e8400-e29b-11d4-a716-446655443402.meta
>>
>>
>> Do you share this opinion?
>
>
> if we are talking about a default persistance manager then yes, but
> if this would be hardcoded, then no ;-)
The question is if the persistence manager should get any
information apart from the UUID. If only the UUID is provided,
there won't be a chance to use human-readable file names.
>> If not, how do you envision the storage structure?
>
>
> I am not sure if we are confusing actual storage with referencing?
>
> well, in order to show what I think how it should be implemented I have
> started
> something at http://svn.wyona.com/repos/public/yanel/trunk
>
> whereas it's not quite working yet and also got distracted on versioned
> published interfaces ... I have done this because I am afraid I will
> never be able to explain my ideas, so I will try to let this code speak.
OK, I'll take a look at it as soon as I find the time.
Thanks for your reply,
-- Andreas
--
Andreas Hartmann
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
andreas.hartmann@wyona.com andreas@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
not yet another out-of-tree prototype :'(
Posted by Jörn Nettingsmeier <po...@uni-duisburg.de>.
Michael Wechner wrote:
> well, in order to show what I think how it should be implemented I have
> started
> something at http://svn.wyona.com/repos/public/yanel/trunk
>
> whereas it's not quite working yet and also got distracted on versioned
> published interfaces ... I have done this because I am afraid I will
> never be able to explain my ideas, so I will try to let this code speak.
i'm sorry, but this code is not going to speak to me. how is anybody in
our small community supposed to read and understand all those alternate
trees?
i have both a life and a job, and while i'm strongly motivated to learn
the lenya trunk and contribute, i lack the resources and leisure time to
dig into yet another complete re-implementation. i hate uml as much as
anyone, but in situations like these i wish people would come up with
boxes and arrows for a change.
--
"Open source takes the bullshit out of software."
- Charles Ferguson on TechnologyReview.com
--
Jörn Nettingsmeier, EDV-Administrator
Institut für Politikwissenschaft
Universität Duisburg-Essen, Standort Duisburg
Mail: pol-admin@uni-due.de, Telefon: 0203/379-2736
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [1.4] UUIDs in persistence layer
Posted by Michael Wechner <mi...@wyona.com>.
Andreas Hartmann wrote:
> Hi Lenya devs,
>
> to sum up the recent UUID discussion:
>
> From my point of view, the next step would be to use UUIDs to
> identify documents. That would mean that the default persistence
> mechanism would store documents in a flat structure which would
> look like this:
>
>
> 550e8400-e29b-11d4-a716-446655440000
> 550e8400-e29b-11d4-a716-446655440000.meta
is 550e8400-e29b-11d4-a716-446655440000 (without suffix meta) the
actual content? I guess you are refering to the reference to the resource,
right?
> 550e8400-e29b-11d4-a716-446655440231
> 550e8400-e29b-11d4-a716-446655440231.meta
> 550e8400-e29b-11d4-a716-446655443402
> 550e8400-e29b-11d4-a716-446655443402.meta
>
>
> Do you share this opinion?
if we are talking about a default persistance manager then yes, but
if this would be hardcoded, then no ;-)
> If not, how do you envision the storage structure?
I am not sure if we are confusing actual storage with referencing?
well, in order to show what I think how it should be implemented I have
started
something at http://svn.wyona.com/repos/public/yanel/trunk
whereas it's not quite working yet and also got distracted on versioned
published interfaces ... I have done this because I am afraid I will
never be able to explain my ideas, so I will try to let this code speak.
Michi
>
> -- Andreas
>
>
--
Michael Wechner
Wyona - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
michael.wechner@wyona.com michi@apache.org
+41 44 272 91 61
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
[1.4] UUIDs in persistence layer (was: Re: Human-readable UUIDs,
languages in UUIDs)
Posted by Andreas Hartmann <an...@apache.org>.
Hi Lenya devs,
to sum up the recent UUID discussion:
From my point of view, the next step would be to use UUIDs to
identify documents. That would mean that the default persistence
mechanism would store documents in a flat structure which would
look like this:
550e8400-e29b-11d4-a716-446655440000
550e8400-e29b-11d4-a716-446655440000.meta
550e8400-e29b-11d4-a716-446655440231
550e8400-e29b-11d4-a716-446655440231.meta
550e8400-e29b-11d4-a716-446655443402
550e8400-e29b-11d4-a716-446655443402.meta
Do you share this opinion?
If not, how do you envision the storage structure?
-- Andreas
--
Andreas Hartmann
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
andreas.hartmann@wyona.com andreas@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org