Re: Re: Archetypes <-> TICLE

Kapil Thangavelu <[email protected]> Tue, 02 Dec 2003 13:27:07 -0800
Newsgroups gmane.comp.web.zope.plone.collective.ticle
Message-ID <BBF243AB.918F%[email protected]>
On 11/24/03 5:08 PM, "Jodok Batlogg" <[email protected]> wrote:

> good evening,
>=20
> if i play customer :)
>

I'll play inquisitive developer that wants to get involved ;-)

>=20
> just one thing on the question AT referencing or not:
>=20
> - i'd like to bring non-AT-objects in relation to AT-objects.
>=20
> it's almost the same with the metadata approach:
>=20
> - CMFMetaData or AT metadata to implement pluggable metadata adapters?
>=20
> what's your feeling on this?

Good point, re non at usage. The point of this exercise for me was to try t=
o
get a respone that would elucidate some of the unclear design goals in the
ticle proposal.

For example I'd like to use non ticle stored content in relations, as
relationships should have nothing to do with where a content is stored. It
seems the original placeless moniker is actually a misnomer, because ticle
is making stringent requirements of where content is stored. Yet, relation
navigation doesn't need to depend on storage or location. The only
precursors to the relation management are content uids and uid -> object
resolution. Indeed the only use case content storage seems to appeal to is
to have ticle available to a pure zodb app, but that use case seems more a
questionable aprori design decision without further justification or users
asking for it.

So it seems ticle should clarify if its trying to be relationship managemen=
t
which is sorely needed or a content repository with integrated relations.
Integration of the latter into plone has many additional hurdles for genera=
l
adoption, assuming that is a use case ;-)

The other concern I wanted to get more discussion information on is the
decision to punt on versioning. Granted that versioning relation graphs is =
a
tricky business, but I think it deserves some consideration, at the least
some possible design or implementation notes. I'm of the opinion that if it=
s
not in the core of ticle than building it on top of ticle would be grossly
inefficient if its even possible.

Also, I wanted to say that I r like the code base and the resultant api is
very pythonic.

Thanks,

kapil



>=20
> thanks
>=20
> jodok
>=20
> Kapil Thangavelu wrote:
>=20
>> This is the why not base on archetypes discussion. I've looked over the
>> source code, and i'm neutral on the matter, but I do want to play devil'=
s
>> advocate for edification purposes. I'm just responding to simon's reply =
see
>> the wiki page for the original strongly worded suggestions.
>>=20
>>=20
>> On 10/7/03 8:07 AM, in article [email protected],
>> "Simon Pamies" <[email protected]> wrote:
>>=20
>> =20
>>=20
>>> (taken from plone.org)
>>> some interesting comments from:
>>>=20
>>> http://plone.org/development/current/projects/ticle_folder/proposal#bot=
tom
>>>=20
>>>=20
>>> Archetypes --spamies, Tue, 07 Oct 2003 11:09:05 -0500
>>> <http://plone.org/development/current/projects/ticle_folder/proposal#ms=
g2003
>>> 10
>>> [email protected]>  reply
>>> <http://plone.org/development/current/projects/ticle_folder/proposal?su=
bject
>>> =3DA
>>> rchetypes&amp;in_reply_to=3D%3C20031007110905-0500%40plone.org%3E#bottom>
>>> I also agree basically with that view. But we have some goals that do n=
ot
>>> match the way that the Archetypes.ReferenceEngine?
>>> <http://plone.org/development/current/projects/ticle_folder/proposal/ed=
itfor
>>> m?
>>> page=3DReferenceEngine>  is going:
>>> * TICLE should deal with 1.000.000 objects and more - I do not think th=
at
>>> the
>>> Archetypes engine can do that
>>>   =20
>>>=20
>>=20
>> Why not? What makes it unable to scale to these dimensions?
>>=20
>> =20
>>=20
>>> * The UID engine do not follow any standards - some of the developers
>>> supporting TICLE absolutely want that feature
>>>   =20
>>>=20
>>=20
>> This is trivial to alter, ben has already done some work on this and oth=
er
>> reference machinery archetypes cvs.
>>=20
>> =20
>>=20
>>> * The Archetype relations are not objects - that makes it difficult to =
add
>>> clean m:n relations or even metadata on objects
>>>   =20
>>>=20
>>=20
>> I'm not sure what makes you think that can't be objects... Because they =
can.
>> See plonecollectorng for example of this. Or look at archetypes cvs wher=
e
>> they are explictly relation objects now.
>>=20
>> Well that=B9s the whole point of basing on archetypes, extending the exist=
ing
>> functionality of the archetypes reference engine with the higher level
>> relation semantics of ticle.
>>=20
>> =20
>>=20
>>> * The engine itself should be useable without Zope/Plone. Archetypes ar=
e
>>> very
>>> plonish=20
>>> Our approach:=20
>>> * Implement that engine without using Zope Core Classes (only ZODB base=
d)
>>>   =20
>>>=20
>>=20
>> What benefit is that? I would think that you have to reinvent so much
>> infrastructure to make it useful that it seems without much merit?
>>=20
>> What sort of features are you planning on a pure zodb level?
>>=20
>>=20
>> =20
>>=20
>>> * Programming Zope Layer
>>> * Programming CMF/Plone Layer that uses Archetypes and perhaps extend t=
hat
>>> wonderful Product. Perhaps we can map the ReferenceEngine?
>>> <http://plone.org/development/current/projects/ticle_folder/proposal/ed=
itfor
>>> m?
>>> page=3DReferenceEngine>  methods to the TICLE engine. That will be the
>>> intergration into the Archetypes Reference Engine..
>>>   =20
>>>=20
>>=20
>> Well if its not going to be part of the implementation than I don't see =
much
>> point to gluing archetypes, as that=B9s a low level interface, and the
>> interface of interest is the higher level one.
>>=20
>> Perhaps you could refine the goal of ticle as stated from the webpage be=
low
>> to make this zodb/zope api layers more clear.
>>=20
>> Ticle deals with the placeless content paradigm, with relations and
>> constraints, with links between objects, with RDF and quite a lot of oth=
er
>> things.
>>=20
>> Browsing through the archives I see mention of lots of items relating to
>> metadata, metadata harvesting, topic maps, rdf. Can the relation of thes=
e
>> technologies to ticle be more explictly defined with reference to its go=
als?
>> For example, Is rdf schema something that=B9s core, or is rdf export the
>> functional intersection of these terms.
>>=20
>> From what I can make of it, ticle is trying to provide a content reposit=
ory
>> with rich semantic relations.
>>=20
>> Once again, I'm neutral wrt to an archetypes impl... Just thought someon=
e
>> should play devil's advocate ;-).
>>=20
>> Apologies in advance if this arrives twice, I'm testing the gmane gatewa=
y.
>>=20
>> sincerely,
>>=20
>> -kapil
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>> -------------------------------------------------------
>> This SF.net email is sponsored by: SF.net Giveback Program.
>> Does SourceForge.net help you be more productive?  Does it
>> help you create better code?  SHARE THE LOVE, and help us help
>> YOU!  Click Here: http://sourceforge.net/donate/
>> _______________________________________________
>> Collective-ticle mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/collective-ticle
>> =20
>>=20
>=20



-------------------------------------------------------
This SF.net email is sponsored by OSDN's Audience Survey.
Help shape OSDN's sites and tell us what you think. Take this
five minute survey and you could win a $250 Gift Certificate.
http://www.wrgsurveys.com/2003/osdntech03.php?site=8