You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lenya.apache.org by Michael Wechner <mi...@wyona.com> on 2006/06/12 19:12:27 UTC

Re: [1.4] UUIDs in persistence layer

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


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