Re: [Collective-versioning] CMFEditions and Archetypes Storage

[Encolpe D. <enc...@in...>]

Grégoire Weber a écrit :
>
> Hi Encolpe,
>
> 2008/1/24, Encolpe Degoute <enc...@in...>:
>> I'm making a FileSystemStorage version compliant with CMFEditions and my
>> investigation let me some questions:
>> FileSystemStorage will implement itself versioning on the filesystem:
>> The actual file become a directory in which versions are stored as files
>> with a RDF file attached for each version. For doing that I need to
>> remove specific fss attributes on the object and to say that the field
>> must not be saved in the repository.
>>
>> Do I need to implement both IAttributeModifier, ICloneModifier and
>> ISaveRetrieveModifier ? Docstings and documentation are not really
>> understandable for me.
> 
> You should always use the ``ISaveRetrieveModifier`` to manipulate attributes
> for objects (e.g. Folders) that do not contain further possibly deep hierarchies.
> This modifier is called *after* the archivist has cloned the object to save and passes
> the clone (``obj_clone`` which is the copy of the original ``obj``). The intention is
> that on being called in the modifier you may manipulate the clone at your will
> (e.g. change or remove attributes, add attributes, etc.).
> 
> In case your object may reference other objects that my further be deeply
> nested you probably need to implement and register an ``ICloneModifier``.
> A clone modifier is called during teh copying process. This may best be
> explaned with an example:
> 
>   Assume you have a hierarchy of folders in your site. You version a folder
>   containg another 10 hierarchies. You may implement a ``ISaveRetrieveModifier``
>   to only version this folder without the 10 hierarchies. But before your modifier
>   is called the whole 10 hierarchies get copied (by the pickle mechanism of the
>   archivist). In the modifier you probably remove this 10 hierarchies.
> 
>   When you implement a `ICloneModifier`` you directly intercept the clone process
>   of the pickle mechanism. For that you have to study the pickle docu and play a
>   little in a sandbox on python level. It's not such complicated.
> 
> Ok, the third modifier (``IAttributeModifier``) should be used if an object contains
> big binaries (like e.g. the file type). This avoids that the multi mega/gigabyte
> binary is passed through the pickle mechanism. In such case the ``IStorage`` has
> to do its own copying of the attribute containing the binary. Some Background:
> If e.g. you implement a SVN storage it doesn't make sense the archivist makes
> a clone of the large binary and the svn storage as well (by sending the binary to
> the svn server as a stream).
> So this modifier is mostly used as optimization and should be considered to
> implemented last (if necessary).

I'm between ``ISaveRetrieveModifier`` and ``IAttributeModifier`` with a
preference to the second one:
I need to call a trigger to said to FSS to store/retrieve a version of
the file and to remove/restore all attributes ending with
'_filesystemstorage_info'.

>> I think we need new interfaces in Archetypes that say to if a storage
>> implement itself the versioning or not.
> 
> Assuming you mean Archetypes storage if you say "storage":

Yes

> - CMFEditions has also a "storage" implementing the histories (as you
>   probably know).
> - Implementing history in AT storage seems to me to be contradictory
>   to the concept of CMFEditions versioning.

Data are store in ZODB in ZVC-Storage as FileSystemStorage allow to
store data outside it. My goal is to allow any AT Storage to be called
by the modifiers if they store data outside ZODB. It makes no sense to
store history data in ZODB where living data are outside it.

> - I'd propose to write a new CMFEditions storage (which is the easiest
>   part in CMFEditions) using the AT storage classes somehow. "Just"
>   implement the ``IStorage`` interface an replace the current ZVC-Storage
>   by your own storage. You may reuse unittests for the existing ZVC
>   storage.

My proposition doesn't affect AT but in adding a marker interface (may
be ``IHistoryStorage``) to let CMFEditions know if it can delegate some
work.

> I do not know AT good enough to know I could help you.
> Did you lok at he architecture?  Please haev a look at
> http://dev.plone.org/collective/browser/CMFEditions/trunk/doc/architecture.pdf
> and various other documents in the ``doc`` folder.

Yes I looked at them.

Regards,
-- 
Encolpe Degoute
INGENIWEB (TM) - S.A.S 50000 Euros - RC B 438 725 632
17 rue Louise Michel - 92300 Levallois Perret - France
web : www.ingeniweb.com - « les Services Web Ingénieux »
Tel : 01.78.15.24.08 / Fax : 01 47 57 39 14