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/13 10:51:49 UTC
[1.4] [RFO] UUID discussion
Hi Lenya devs,
IMO the UUID issue is quite important regarding the upcoming 1.4 release,
and I'm very interested in your opinions about this topic.
I can see the following options, would you mind adding your +1
to one of them or add another one?
1) We should release 1.4 without UUIDs, the issue is to complex
and should be discussed in detail later on.
2) We should introduce UUIDs in a straightforward manner:
- sitetree references documents using UUIDs
- the persistence layer knows only about UUIDs
- the default persistence impl. uses UUID+language as filename
- links are resolved when a page is rendered
3) The concept of paths should be kept. URLs are mapped to paths,
i.e. the sitetree contains path references. The URL space
might change, the path space might not (otherwise we would
still be moving documents around, which is IMO a bad thing).
4) It should be in 1.4, but I don't like options (2) and (3).
IMO it should be implemented like this:
...
----
Another issue: UUIDs vs. UNIDs
Do you prefer
a) UUIDs (http://en.wikipedia.org/wiki/UUID)
b) Lenya-specific UNIDs which might be human-readable
Thanks a lot in advance!
-- 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] [RFO] UUID discussion
Posted by Jörn Nettingsmeier <po...@uni-duisburg.de>.
Andreas Hartmann wrote:
> Andreas Hartmann wrote:
>
> [...]
>
>>>
>>> Another issue: UUIDs vs. UNIDs
>>>
>>> Do you prefer
>>>
>>> a) UUIDs (http://en.wikipedia.org/wiki/UUID)
>
> +1
>
>>> b) Lenya-specific UNIDs which might be human-readable
>>
>> +1
>
> Reverting: -1
>> I'd like something human-readable (like in a Wiki) here.
>> Note that this identifier is not related to the URL space.
>> The human-readable UNID would have the advantage that documents
>> can be deleted, archived, restored etc. independent from
>> the URL space and can be identified later on.
>
> I'm reverting this - we just can't require to enter human-
> readable UNIDs. This is not manageable, for instance when a great
> amount of documents are imported.
>
> If someone wants human-readable identifiers, she should use
> meta data for this purpose.
i prefer UUIDs as well, for the same resons as andreas.
in addition, we should take care that a nice human-readable mapping from
document names to uuid files is available *outside of the lenya api*,
for example in the sitetree.xml file, so that it can be parsed with
standard unix or xml tools if manual intervention becomes necessary.
--
"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] [RFO] UUID discussion
Posted by Andreas Hartmann <an...@apache.org>.
Andreas Hartmann wrote:
[...]
>>
>> Another issue: UUIDs vs. UNIDs
>>
>> Do you prefer
>>
>> a) UUIDs (http://en.wikipedia.org/wiki/UUID)
+1
>> b) Lenya-specific UNIDs which might be human-readable
>
> +1
Reverting: -1
> I'd like something human-readable (like in a Wiki) here.
> Note that this identifier is not related to the URL space.
> The human-readable UNID would have the advantage that documents
> can be deleted, archived, restored etc. independent from
> the URL space and can be identified later on.
I'm reverting this - we just can't require to enter human-
readable UNIDs. This is not manageable, for instance when a great
amount of documents are imported.
If someone wants human-readable identifiers, she should use
meta data for this purpose.
-- 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] [RFO] UUID discussion
Posted by Andreas Hartmann <an...@apache.org>.
Joachim Wolfgang Kaltz wrote:
> Andreas Hartmann schrieb:
>> (...)
>> Maybe the identification problem (e.g. restoring after archiving)
>> could be solved by meta data queries etc. Or maybe you have another
>> idea how to solve it? Or do we have to design the system in a way that
>> this should never be necessary?
>
> IMO identification in that sense is dependent on how a specific
> publication ("default", "wiki", "blog", ...) constructs a site based on:
> - a bunch of content items (stored by the repository)
> - a navigation model (for example, the sitetree xml of the default
> publication)
>
> If the navigation model is just some XML file (like the sitetree in the
> default publication), you can store that too in the repository. I'm not
> sure I see a problem for restoring after archiving in this case ?
>
> If somebody creates a different publication, with a different navigation
> model that is not easily restored, then she is responsible for
> implementing publication-specific restoration.
That sounds reasonable.
Thanks for your comments!
-- 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] [RFO] UUID discussion
Posted by Joachim Wolfgang Kaltz <jo...@uni-duisburg-essen.de>.
Andreas Hartmann schrieb:
> (...)
> Maybe the identification problem (e.g. restoring after archiving)
> could be solved by meta data queries etc. Or maybe you have another
> idea how to solve it? Or do we have to design the system in a way that
> this should never be necessary?
IMO identification in that sense is dependent on how a specific
publication ("default", "wiki", "blog", ...) constructs a site based on:
- a bunch of content items (stored by the repository)
- a navigation model (for example, the sitetree xml of the default
publication)
If the navigation model is just some XML file (like the sitetree in the
default publication), you can store that too in the repository. I'm not
sure I see a problem for restoring after archiving in this case ?
If somebody creates a different publication, with a different navigation
model that is not easily restored, then she is responsible for
implementing publication-specific restoration.
--
Wolfgang
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [1.4] [RFO] UUID discussion
Posted by Andreas Hartmann <an...@apache.org>.
Joachim Wolfgang Kaltz wrote:
> Andreas Hartmann schrieb:
[...]
>> I'd like something human-readable (like in a Wiki) here.
>> Note that this identifier is not related to the URL space.
>> The human-readable UNID would have the advantage that documents
>> can be deleted, archived, restored etc. independent from
>> the URL space and can be identified later on.
>
> Wouldn't this put the burden on the user to come up with a unique,
> human-readable id, for a piece of content ?
Yes ...
[...]
> What about another example "CS100" (introductory computer
> science lecture). Would the user have to say "CS100_fall_2006" as a
> unique id, or would she be able to create a new entry "CS100" under
> "Lectures" / "Fall 2006" ?
It would have to be "CS100_fall_2006", but I understand that this is
indeed hardly acceptable. The other option (CS100/Lectures/Fall2006)
would imply a path-based document organization structure (independent
from the URL space), only the leaf nodes would be documents:
URL -> [ path <-> UUID ]
Note that not all paths would point to UUIDs, since some paths
are only used as folders.
Michi, does this resemble your ideas?
If we don't require human-readable UNIDs or paths:
Maybe the identification problem (e.g. restoring after archiving)
could be solved by meta data queries etc. Or maybe you have another
idea how to solve it? Or do we have to design the system in a way that
this should never be necessary?
-- 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] [RFO] UUID discussion
Posted by Joachim Wolfgang Kaltz <jo...@uni-duisburg-essen.de>.
Andreas Hartmann schrieb:
>
> BTW, here's my own opinion:
> (...)
>> Do you prefer
>>
>> a) UUIDs (http://en.wikipedia.org/wiki/UUID)
>>
>> b) Lenya-specific UNIDs which might be human-readable
>
>
> +1
>
> I'd like something human-readable (like in a Wiki) here.
> Note that this identifier is not related to the URL space.
> The human-readable UNID would have the advantage that documents
> can be deleted, archived, restored etc. independent from
> the URL space and can be identified later on.
Wouldn't this put the burden on the user to come up with a unique,
human-readable id, for a piece of content ?
IMO when you want a site to follow the Wiki principle, you should use
the "WikiPublication", which works like a Wiki, on the surface. That
means, for the user, there is no hierarchy, just a bunch of keywords
(which the users choose) and which must be unique.
In this publication, the wiki entry name is of course also stored by
Lenya, but only relevant for things like the navigation layer, not
defining the repository ids.
> Example:
>
> The
>
> URL /home/news
>
> is mapped to the document with the
>
> UNID NewsOverview (language "en")
well, "news" sounds like an example picked for something that is indeed
unique ;) What about another example "CS100" (introductory computer
science lecture). Would the user have to say "CS100_fall_2006" as a
unique id, or would she be able to create a new entry "CS100" under
"Lectures" / "Fall 2006" ?
--
Wolfgang
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [1.4] [RFO] UUID discussion
Posted by Andreas Hartmann <an...@apache.org>.
BTW, here's my own opinion:
Andreas Hartmann wrote:
> 2) We should introduce UUIDs in a straightforward manner:
>
> - sitetree references documents using UUIDs
> - the persistence layer knows only about UUIDs
> - the default persistence impl. uses UUID+language as filename
> - links are resolved when a page is rendered
+1
whereas UUID should be replaced with UNID (see below).
> ----
>
> Another issue: UUIDs vs. UNIDs
>
> Do you prefer
>
> a) UUIDs (http://en.wikipedia.org/wiki/UUID)
>
> b) Lenya-specific UNIDs which might be human-readable
+1
I'd like something human-readable (like in a Wiki) here.
Note that this identifier is not related to the URL space.
The human-readable UNID would have the advantage that documents
can be deleted, archived, restored etc. independent from
the URL space and can be identified later on.
Example:
The
URL /home/news
is mapped to the document with the
UNID NewsOverview (language "en")
which might be stored by the file-system storage in the
file /content/authoring/NewsOverview_en
or by the JCR-based storage in the
node /content/NewsOverview
-- 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] [RFO] UUID discussion
Posted by Joachim Wolfgang Kaltz <jo...@uni-duisburg-essen.de>.
Andreas Hartmann schrieb:
> Hi Lenya devs,
>
> IMO the UUID issue is quite important regarding the upcoming 1.4 release,
> and I'm very interested in your opinions about this topic.
>
> I can see the following options, would you mind adding your +1
> to one of them or add another one?
>
>
> 1) We should release 1.4 without UUIDs, the issue is to complex
> and should be discussed in detail later on.
+1
unless UUIDs would solve some issue which is now blocking the release of 1.4
> ...
>
> ----
>
> Another issue: UUIDs vs. UNIDs
>
> Do you prefer
>
> a) UUIDs (http://en.wikipedia.org/wiki/UUID)
+1
>
> b) Lenya-specific UNIDs which might be human-readable
not from a repository storage point-of-view (will reply to your other
mail separately)
--
Wolfgang
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [1.4] [RFO] UUID discussion
Posted by Jörn Nettingsmeier <po...@uni-duisburg.de>.
Andreas Hartmann wrote:
> Josias Thöny wrote:
>> One thing which hasn't been discussed yet is how internal links would
>> look like in the xml. Can we still use the xhtml:a element?
>> <xhtml:a href="550e8400-e29b-11d4-a716-446655440000_en">foo</xhtml:a>
>>
>> Or with a special scheme:
>> <xhtml:a
>> href="lenyalink://550e8400-e29b-11d4-a716-446655440000_en">foo</xhtml:a>
>
> I'd prefer this option, maybe even
>
> lenyalink://550e8400-e29b-11d4-a716-446655440000/en
>
> to clearly separate UUID and language.
>
>> Or do we need a new element, like e.g.
>> <lenya:link uuid="550e8400-e29b-11d4-a716-446655440000"
>> lang="en">foo<lenya:link>
>
> I'm not quite sure - the first option has the advantage that the XML
> schema is not affected, but the second makes it clearer what is to
> be treated as an (internal) link.
i strongly prefer the normal xhtml:a element over a special one. the
lenyadoc:// protocol scheme makes it sufficiently clear that those links
are special, and this scheme can be re-used in other tags such as <img
src=""/>, <object/>, <link/> etc. with custom tags, we would need our
own custom tags for each of those...
--
"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] [RFO] UUID discussion
Posted by Andreas Hartmann <an...@apache.org>.
Josias Thöny wrote:
[...]
>> - change site managers to return UUIDs for URLs
>> - implement link resolving component
>> - update "Insert Link" editor functionality
>> - update DocumentManagerImpl not to move sources when content is moved
>> - check which other parts of the code will be affected
>> (document ID string magic)
>>
>> What did I forget?
>
> Perhaps a migration tool?
Yes, that's an important point.
> One thing which hasn't been discussed yet is how internal links would
> look like in the xml. Can we still use the xhtml:a element?
> <xhtml:a href="550e8400-e29b-11d4-a716-446655440000_en">foo</xhtml:a>
>
> Or with a special scheme:
> <xhtml:a
> href="lenyalink://550e8400-e29b-11d4-a716-446655440000_en">foo</xhtml:a>
I'd prefer this option, maybe even
lenyalink://550e8400-e29b-11d4-a716-446655440000/en
to clearly separate UUID and language.
> Or do we need a new element, like e.g.
> <lenya:link uuid="550e8400-e29b-11d4-a716-446655440000"
> lang="en">foo<lenya:link>
I'm not quite sure - the first option has the advantage that the XML
schema is not affected, but the second makes it clearer what is to
be treated as an (internal) link.
Maybe the first option in connection with
ResourceType.getLinkAttributeXPaths() is sufficient.
On the other hand, the <lenya:link> concept seems cleaner than the
link attribute XPath solution ...
-- 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] [RFO] UUID discussion
Posted by Josias Thöny <jo...@wyona.com>.
On Thu, 2006-06-15 at 09:14 +0200, Andreas Hartmann wrote:
> Antonio Gallardo wrote:
> > Michael Wechner escribió:
> >> Andreas Hartmann wrote:
> >>> Hi Lenya devs,
> >>>
> >>> IMO the UUID issue is quite important regarding the upcoming 1.4
> >>> release,
> >>> and I'm very interested in your opinions about this topic.
> >>>
> >>> I can see the following options, would you mind adding your +1
> >>> to one of them or add another one?
> >>>
> >>>
> >>> 1) We should release 1.4 without UUIDs, the issue is to complex
> >>> and should be discussed in detail later on.
> >>
> >> -1 because we are just postponing one of the most important problems
> >> Lenya has until
> >> tomorrow and I think we would waste a lot of resources again and again
> >> and again ...
> > How much time do you think is needed to implement this?
>
> From my point of view, the following things have to be done:
>
> - change site managers to return UUIDs for URLs
> - implement link resolving component
> - update "Insert Link" editor functionality
> - update DocumentManagerImpl not to move sources when content is moved
> - check which other parts of the code will be affected
> (document ID string magic)
>
> What did I forget?
Perhaps a migration tool?
One thing which hasn't been discussed yet is how internal links would
look like in the xml. Can we still use the xhtml:a element?
<xhtml:a href="550e8400-e29b-11d4-a716-446655440000_en">foo</xhtml:a>
Or with a special scheme:
<xhtml:a
href="lenyalink://550e8400-e29b-11d4-a716-446655440000_en">foo</xhtml:a>
Or do we need a new element, like e.g.
<lenya:link uuid="550e8400-e29b-11d4-a716-446655440000"
lang="en">foo<lenya:link>
WDYT?
Josias
>
> -- Andreas
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [1.4] [RFO] UUID discussion
Posted by Andreas Hartmann <an...@apache.org>.
Antonio Gallardo wrote:
> Michael Wechner escribió:
>> Andreas Hartmann wrote:
>>> Hi Lenya devs,
>>>
>>> IMO the UUID issue is quite important regarding the upcoming 1.4
>>> release,
>>> and I'm very interested in your opinions about this topic.
>>>
>>> I can see the following options, would you mind adding your +1
>>> to one of them or add another one?
>>>
>>>
>>> 1) We should release 1.4 without UUIDs, the issue is to complex
>>> and should be discussed in detail later on.
>>
>> -1 because we are just postponing one of the most important problems
>> Lenya has until
>> tomorrow and I think we would waste a lot of resources again and again
>> and again ...
> How much time do you think is needed to implement this?
From my point of view, the following things have to be done:
- change site managers to return UUIDs for URLs
- implement link resolving component
- update "Insert Link" editor functionality
- update DocumentManagerImpl not to move sources when content is moved
- check which other parts of the code will be affected
(document ID string magic)
What did I forget?
-- 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] [RFO] UUID discussion
Posted by Jörn Nettingsmeier <po...@uni-duisburg.de>.
Michael Wechner wrote:
>> How much time do you think is needed to implement this?
> Well, I could give you an answer, but your question will lead myself
> into a conflict of interests, so I won't
> really answer it, but it shouldn't take very long if somebody is
> actually taking the time to do it, but how should I know ;-)
:-D
let's create a lenya zen garden somewhere with these words of wisdom to
greet the visitors ;)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [1.4] [RFO] UUID discussion
Posted by Michael Wechner <mi...@wyona.com>.
Antonio Gallardo wrote:
> Michael Wechner escribió:
>> Andreas Hartmann wrote:
>>> Hi Lenya devs,
>>>
>>> IMO the UUID issue is quite important regarding the upcoming 1.4
>>> release,
>>> and I'm very interested in your opinions about this topic.
>>>
>>> I can see the following options, would you mind adding your +1
>>> to one of them or add another one?
>>>
>>>
>>> 1) We should release 1.4 without UUIDs, the issue is to complex
>>> and should be discussed in detail later on.
>>
>> -1 because we are just postponing one of the most important problems
>> Lenya has until
>> tomorrow and I think we would waste a lot of resources again and
>> again and again ...
> How much time do you think is needed to implement this?
Well, I could give you an answer, but your question will lead myself
into a conflict of interests, so I won't
really answer it, but it shouldn't take very long if somebody is
actually taking the time to do it, but how should I know ;-)
Michi
>
> Best Regards,
>
> Antonio Gallardo
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
> For additional commands, e-mail: dev-help@lenya.apache.org
>
>
--
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] [RFO] UUID discussion
Posted by Antonio Gallardo <ag...@agssa.net>.
Michael Wechner escribió:
> Andreas Hartmann wrote:
>> Hi Lenya devs,
>>
>> IMO the UUID issue is quite important regarding the upcoming 1.4
>> release,
>> and I'm very interested in your opinions about this topic.
>>
>> I can see the following options, would you mind adding your +1
>> to one of them or add another one?
>>
>>
>> 1) We should release 1.4 without UUIDs, the issue is to complex
>> and should be discussed in detail later on.
>
> -1 because we are just postponing one of the most important problems
> Lenya has until
> tomorrow and I think we would waste a lot of resources again and again
> and again ...
How much time do you think is needed to implement this?
Best Regards,
Antonio Gallardo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [1.4] [RFO] UUID discussion
Posted by Michael Wechner <mi...@wyona.com>.
Andreas Hartmann wrote:
> Hi Lenya devs,
>
> IMO the UUID issue is quite important regarding the upcoming 1.4 release,
> and I'm very interested in your opinions about this topic.
>
> I can see the following options, would you mind adding your +1
> to one of them or add another one?
>
>
> 1) We should release 1.4 without UUIDs, the issue is to complex
> and should be discussed in detail later on.
-1 because we are just postponing one of the most important problems
Lenya has until
tomorrow and I think we would waste a lot of resources again and again
and again ...
>
>
> 2) We should introduce UUIDs in a straightforward manner:
>
> - sitetree references documents using UUIDs
I guess you mean something like
<site>
<node uuid="..."
+1
> - the persistence layer knows only about UUIDs
-1, resp. I think we should also pass the path but do the default
implementation with UUID
> - the default persistence impl. uses UUID+language as filename
+1 (but please see above)
> - links are resolved when a page is rendered
+1 resp. is there any alternative ;-) ?
>
>
> 3) The concept of paths should be kept. URLs are mapped to paths,
> i.e. the sitetree contains path references. The URL space
> might change, the path space might not
I would consider this the VirtualFileSystem implementation and I would
be happy
to implement this as an alternative to the default from above, but it
would require that
the path is passed to the persistance manager...
> (otherwise we would
> still be moving documents around, which is IMO a bad thing).
very much agreed
>
>
> 4) It should be in 1.4, but I don't like options (2) and (3).
> IMO it should be implemented like this:
> ...
>
> ----
>
> Another issue: UUIDs vs. UNIDs
>
> Do you prefer
>
> a) UUIDs (http://en.wikipedia.org/wiki/UUID)
>
> b) Lenya-specific UNIDs which might be human-readable
what about a factory ... ?
Thanks
Michi
>
>
> Thanks a lot in advance!
>
> -- 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] [RFO] UUID discussion
Posted by "Gregor J. Rothfuss" <gr...@apache.org>.
Andreas Hartmann wrote:
> 1) We should release 1.4 without UUIDs, the issue is to complex
> and should be discussed in detail later on.
+1
> 2) We should introduce UUIDs in a straightforward manner:
>
> - sitetree references documents using UUIDs
> - the persistence layer knows only about UUIDs
> - the default persistence impl. uses UUID+language as filename
> - links are resolved when a page is rendered
+1, at a later date
> 3) The concept of paths should be kept. URLs are mapped to paths,
> i.e. the sitetree contains path references. The URL space
> might change, the path space might not (otherwise we would
> still be moving documents around, which is IMO a bad thing).
-1
> a) UUIDs (http://en.wikipedia.org/wiki/UUID)
+1
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [1.4] [RFO] UUID discussion
Posted by Antonio Gallardo <ag...@agssa.net>.
solprovider@apache.org escribió:
> I do not understand why this discussion is so long. Write the code to
> handle any String. This week use UUIDs. Next week use ServerID +
> SeqNum. The week after that, use that custom generator some developer
> thinks is cool. Then later go back to UUIDs. The code should
> understand all the UNIDs without touching Resources created with a
> different algorithm (unless the formats overlap). Make it easy to
> plug in different generators for getNextUNID(), and everybody will be
> happy.
+1 After all, it should allow more flexibility.
Best Regards,
Antonio Gallardo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [1.4] [RFO] UUID discussion
Posted by so...@apache.org.
On 6/14/06, Gregor J. Rothfuss <gr...@apache.org> wrote:
> solprovider@apache.org wrote:
> > Sequential numbers: 0001, 0002, 0003, etc. Padded to look pretty in a
> > directory. This format is fine for the migration, but is a poor
> > choice if Resources are created on multiple servers.
> that pretty much guarantees problems if you have several people writing
> to the repo concurrently.
No, it would not be a problem for multiple people creating Resources
on a single server; just synchronize() the function that assigns the
next number. It is a problem when multiple servers (and clients) are
creating Resources. With a pure sequence, every server must phone
home for the next number, or duplicates will happen. There are
methods to resolve duplicates, but why bother?
Another method is to prefix every UNID with the server ID. All server
#1 UNIDs begin with "A". All server #2 UNIDs begin with "B". Then
sequential numbering works because the UNIDs created by different
servers cannot conflict.
For a migration routine running as a batch job on a single server,
sequential numbering works great. The "New Resource" function will not
use sequential numbering, but there is little reason to change the
migration routine. Lenya1.3 can easily mix formats.
I do not understand why this discussion is so long. Write the code to
handle any String. This week use UUIDs. Next week use ServerID +
SeqNum. The week after that, use that custom generator some developer
thinks is cool. Then later go back to UUIDs. The code should
understand all the UNIDs without touching Resources created with a
different algorithm (unless the formats overlap). Make it easy to
plug in different generators for getNextUNID(), and everybody will be
happy.
solprovider
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [1.4] [RFO] UUID discussion
Posted by "Gregor J. Rothfuss" <gr...@apache.org>.
solprovider@apache.org wrote:
> Sequential numbers: 0001, 0002, 0003, etc. Padded to look pretty in a
> directory. This format is fine for the migration, but is a poor
> choice if Resources are created on multiple servers.
that pretty much guarantees problems if you have several people writing
to the repo concurrently.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [1.4] [RFO] UUID discussion
Posted by Michael Wechner <mi...@wyona.com>.
solprovider@apache.org wrote:
> On 6/14/06, Thorsten Scherler <th...@apache.org> wrote:
>> I think we should talk about blockers, resolve them and do a 1.4.1
>> release. I hope that many committer will review the 1.3 revolution and
>> then we should start a 1.5 branch where we take the best from 1.3 and
>> 1.4 and add all new features that are still missing 1.4.
>
> 1.3 uses UNIDs. The "New Resource" code has not been written yet, so
> any format is fine. The migration (from 1.2) routine is easy to
> change to any format. The UNIDs can be:
>
> Sequential numbers: 0001, 0002, 0003, etc. Padded to look pretty in a
> directory. This format is fine for the migration, but is a poor
> choice if Resources are created on multiple servers.
>
> UUIDs: Big long guaranteed unique numbers. Anything involving
> multiple servers should use them. (Domino mixes this with sequential
> numbering. Each datastore sequentially numbers the Resources in its
> own datastore, but assigns a UUID to uniquely identify each Resource
> when merging datastores.)
>
> IDs: Start with the ID assigned by the creator of the Resource. Add a
> suffix if it is not unique. Never change the UNID.
> Resource #1 ID="news" UNID="news"
> Resource #2 ID="news" UNID="news1"
> Change Resource #1's ID="oldnews", UNID is still "news".
> This has the multi-server issues of sequential numbering, and adds
> confusion when IDs are changed.
>
> Lenya1.3 can mix all formats, as long as each UNID is unique (and can
> be a directory name). My current plan is to keep the migration
> routine using the sequential numbers, but all new Resources are
> assigned a UUID as the UNID.
>
> 1.3 Vistors see hierarchical IDs, just like 1.2. Maintenance must be
> handled with UNIDs, since IDs are not unique. Even with the flat
> datastore, there could be a page with the hierarchical ID:
> news/news/news.html
this is why I suggested a factory ;-)
Michi
>
> solprovider
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
> For additional commands, e-mail: dev-help@lenya.apache.org
>
>
--
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] [RFO] UUID discussion
Posted by so...@apache.org.
On 6/14/06, Thorsten Scherler <th...@apache.org> wrote:
> I think we should talk about blockers, resolve them and do a 1.4.1
> release. I hope that many committer will review the 1.3 revolution and
> then we should start a 1.5 branch where we take the best from 1.3 and
> 1.4 and add all new features that are still missing 1.4.
1.3 uses UNIDs. The "New Resource" code has not been written yet, so
any format is fine. The migration (from 1.2) routine is easy to
change to any format. The UNIDs can be:
Sequential numbers: 0001, 0002, 0003, etc. Padded to look pretty in a
directory. This format is fine for the migration, but is a poor
choice if Resources are created on multiple servers.
UUIDs: Big long guaranteed unique numbers. Anything involving
multiple servers should use them. (Domino mixes this with sequential
numbering. Each datastore sequentially numbers the Resources in its
own datastore, but assigns a UUID to uniquely identify each Resource
when merging datastores.)
IDs: Start with the ID assigned by the creator of the Resource. Add a
suffix if it is not unique. Never change the UNID.
Resource #1 ID="news" UNID="news"
Resource #2 ID="news" UNID="news1"
Change Resource #1's ID="oldnews", UNID is still "news".
This has the multi-server issues of sequential numbering, and adds
confusion when IDs are changed.
Lenya1.3 can mix all formats, as long as each UNID is unique (and can
be a directory name). My current plan is to keep the migration
routine using the sequential numbers, but all new Resources are
assigned a UUID as the UNID.
1.3 Vistors see hierarchical IDs, just like 1.2. Maintenance must be
handled with UNIDs, since IDs are not unique. Even with the flat
datastore, there could be a page with the hierarchical ID:
news/news/news.html
solprovider
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [1.4] [RFO] UUID discussion
Posted by Michael Wechner <mi...@wyona.com>.
Thorsten Scherler wrote:
>
> I think we should talk about blockers,
I think the UUID problem is a blocker ;-)
> resolve them and do a 1.4.1
> release. I hope that many committer will review the 1.3 revolution and
> then we should start a 1.5 branch where we take the best from 1.3 and
> 1.4 and add all new features that are still missing 1.4.
>
> 1.4 is way too long in development then to have radical changes since
> this means all 1.4.
it's not a radical change, but rather finish something which we have
started and prepared quite some
time ago
> projects that are already in production would have
> to be ported.
>
better now, than later
Michi
> salu2
>
>
>> -- Andreas
>>
>>
>>
>>> If that can not be granted i will vote for
>>> option 2.
>>>
>>>
>>>> 2) We should introduce UUIDs in a straightforward manner:
>>>>
>>>> - sitetree references documents using UUIDs
>>>> - the persistence layer knows only about UUIDs
>>>> - the default persistence impl. uses UUID+language as filename
>>>> - links are resolved when a page is rendered
>>>>
>>>>
>>>> 3) The concept of paths should be kept. URLs are mapped to paths,
>>>> i.e. the sitetree contains path references. The URL space
>>>> might change, the path space might not (otherwise we would
>>>> still be moving documents around, which is IMO a bad thing).
>>>>
>>>>
>>>> 4) It should be in 1.4, but I don't like options (2) and (3).
>>>> IMO it should be implemented like this:
>>>> ...
>>>>
>>>> ----
>>>>
>>>> Another issue: UUIDs vs. UNIDs
>>>>
>>>> Do you prefer
>>>>
>>>> a) UUIDs (http://en.wikipedia.org/wiki/UUID)
>>>>
>>>>
>>> +1
>>>
>>>
>>>> b) Lenya-specific UNIDs which might be human-readable
>>>>
>>>>
>>>>
>>> Jann
>>>
>>
--
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] [RFO] UUID discussion
Posted by Thorsten Scherler <th...@apache.org>.
El mar, 13-06-2006 a las 17:52 +0200, Andreas Hartmann escribió:
> Jann Forrer wrote:
> > Andreas Hartmann wrote:
> >> Hi Lenya devs,
> >>
> >> IMO the UUID issue is quite important regarding the upcoming 1.4 release,
> >> and I'm very interested in your opinions about this topic.
> >>
> >> I can see the following options, would you mind adding your +1
> >> to one of them or add another one?
> >>
> >>
> >> 1) We should release 1.4 without UUIDs, the issue is to complex
> >> and should be discussed in detail later on.
> >>
> >
> > +1
> >
> > At the moment I can not estimate how complex it really is but it seems
> > important to me that 1.4 is realeased as soon as possible. The UUID can
> > be planned for a next release e.g. 1.4.1. However in that case it has to
> > be backward compatible.
>
> It will probably not be backwards-compatible, since there will be
> changes to the API and to the content structure. Actually I think that
> the impact on the code base is rather large, and that it shouldn't
> be scheduled for 1.4.1 but rather for 1.4 or 1.6. What do the others
> think?
I am really not sure. We need to release 1.4 now as long we have this
momentum. UUIDs will change the API. Meaning that current projects need
to be ported to this changes.
I think we should talk about blockers, resolve them and do a 1.4.1
release. I hope that many committer will review the 1.3 revolution and
then we should start a 1.5 branch where we take the best from 1.3 and
1.4 and add all new features that are still missing 1.4.
1.4 is way too long in development then to have radical changes since
this means all 1.4. projects that are already in production would have
to be ported.
salu2
>
> -- Andreas
>
>
> > If that can not be granted i will vote for
> > option 2.
> >
> >>
> >> 2) We should introduce UUIDs in a straightforward manner:
> >>
> >> - sitetree references documents using UUIDs
> >> - the persistence layer knows only about UUIDs
> >> - the default persistence impl. uses UUID+language as filename
> >> - links are resolved when a page is rendered
> >>
> >>
> >> 3) The concept of paths should be kept. URLs are mapped to paths,
> >> i.e. the sitetree contains path references. The URL space
> >> might change, the path space might not (otherwise we would
> >> still be moving documents around, which is IMO a bad thing).
> >>
> >>
> >> 4) It should be in 1.4, but I don't like options (2) and (3).
> >> IMO it should be implemented like this:
> >> ...
> >>
> >> ----
> >>
> >> Another issue: UUIDs vs. UNIDs
> >>
> >> Do you prefer
> >>
> >> a) UUIDs (http://en.wikipedia.org/wiki/UUID)
> >>
> >
> > +1
> >
> >> b) Lenya-specific UNIDs which might be human-readable
> >>
> >>
> > Jann
>
>
--
thorsten
"Together we stand, divided we fall!"
Hey you (Pink Floyd)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org
Re: [1.4] [RFO] UUID discussion
Posted by Andreas Hartmann <an...@apache.org>.
Jann Forrer wrote:
> Andreas Hartmann wrote:
>> Hi Lenya devs,
>>
>> IMO the UUID issue is quite important regarding the upcoming 1.4 release,
>> and I'm very interested in your opinions about this topic.
>>
>> I can see the following options, would you mind adding your +1
>> to one of them or add another one?
>>
>>
>> 1) We should release 1.4 without UUIDs, the issue is to complex
>> and should be discussed in detail later on.
>>
>
> +1
>
> At the moment I can not estimate how complex it really is but it seems
> important to me that 1.4 is realeased as soon as possible. The UUID can
> be planned for a next release e.g. 1.4.1. However in that case it has to
> be backward compatible.
It will probably not be backwards-compatible, since there will be
changes to the API and to the content structure. Actually I think that
the impact on the code base is rather large, and that it shouldn't
be scheduled for 1.4.1 but rather for 1.4 or 1.6. What do the others
think?
-- Andreas
> If that can not be granted i will vote for
> option 2.
>
>>
>> 2) We should introduce UUIDs in a straightforward manner:
>>
>> - sitetree references documents using UUIDs
>> - the persistence layer knows only about UUIDs
>> - the default persistence impl. uses UUID+language as filename
>> - links are resolved when a page is rendered
>>
>>
>> 3) The concept of paths should be kept. URLs are mapped to paths,
>> i.e. the sitetree contains path references. The URL space
>> might change, the path space might not (otherwise we would
>> still be moving documents around, which is IMO a bad thing).
>>
>>
>> 4) It should be in 1.4, but I don't like options (2) and (3).
>> IMO it should be implemented like this:
>> ...
>>
>> ----
>>
>> Another issue: UUIDs vs. UNIDs
>>
>> Do you prefer
>>
>> a) UUIDs (http://en.wikipedia.org/wiki/UUID)
>>
>
> +1
>
>> b) Lenya-specific UNIDs which might be human-readable
>>
>>
> Jann
--
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] [RFO] UUID discussion
Posted by Jann Forrer <ja...@id.unizh.ch>.
Andreas Hartmann wrote:
> Hi Lenya devs,
>
> IMO the UUID issue is quite important regarding the upcoming 1.4 release,
> and I'm very interested in your opinions about this topic.
>
> I can see the following options, would you mind adding your +1
> to one of them or add another one?
>
>
> 1) We should release 1.4 without UUIDs, the issue is to complex
> and should be discussed in detail later on.
>
+1
At the moment I can not estimate how complex it really is but it seems
important to me that 1.4 is realeased as soon as possible. The UUID can
be planned for a next release e.g. 1.4.1. However in that case it has to
be backward compatible. If that can not be granted i will vote for
option 2.
>
> 2) We should introduce UUIDs in a straightforward manner:
>
> - sitetree references documents using UUIDs
> - the persistence layer knows only about UUIDs
> - the default persistence impl. uses UUID+language as filename
> - links are resolved when a page is rendered
>
>
> 3) The concept of paths should be kept. URLs are mapped to paths,
> i.e. the sitetree contains path references. The URL space
> might change, the path space might not (otherwise we would
> still be moving documents around, which is IMO a bad thing).
>
>
> 4) It should be in 1.4, but I don't like options (2) and (3).
> IMO it should be implemented like this:
> ...
>
> ----
>
> Another issue: UUIDs vs. UNIDs
>
> Do you prefer
>
> a) UUIDs (http://en.wikipedia.org/wiki/UUID)
>
+1
> b) Lenya-specific UNIDs which might be human-readable
>
>
Jann
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lenya.apache.org
For additional commands, e-mail: dev-help@lenya.apache.org