[Zope3-dev] Object Status Info

Tres Seaver tseaver@zope.com
Wed, 10 Apr 2002 08:02:54 -0400


Stephan Richter wrote:
> At 10:37 PM 4/9/2002 -0400, Guido van Rossum wrote:
> 
>> > for FTP support I need to know some information about objects.
>>
>> I think it would be handy to have such info available in the ZMI too.
> 
> 
> I agree.
> 
>> > I need:
>> >
>> > - the access mode a la Unix (can be probably found after security is 
>> done)
>>
>> I think some other access mode abstraction could probably be easily
>> translated.  Really all you need is whether the user who's logged in
>> (or "nobody") can read/write the object; ftp doesn't really care for
>> anything else.
> 
> 
> Yep, I just thought it would be nice to try to map everything.

See Shane's list of adapter interfaces.

> 
>> > - Owner and owner group of the object (I assume that will also come 
>> from
>> > the security mechanism somehow)
>>
>> If these are the proper concepts in the Zope security philosophy --
>> I've lost track of the discussion on groups.  Note that ftp really
>> doesn't require Unix-style output -- that's just the most common form.
>>
>> > - Size of object (right now it checks whether a method getSize exists)
>>
>> Calculated how?
> 
> 
> IFiles stores the size of their content. So it is not the size of the 
> actual object, but the content it contains, which is what we need for FTP.
> 
>> > - Access, Modification and Creation time. I think that information 
>> should
>> > be stored in the container of the object.
>>
>> Would be nice to have indeed.  (Though Unix ctime isn't really
>> creation time -- it's time of last change to metadata.)  I think ZODB
>> stores the mtime.
> 
> 
> That would be cool. I hoped for that! :-)

Speaking from painful experience:

'bobobase_modification_time' is *not* the right semantic for 'mtime' here;
the issue is that there is no one-to-one mapping of "filesystem listing
entries" to DB records.  The modification time should be stored explicitly.

> 
>>   The atime may be hard to come by without causing inefficiencies.
> 
> 
> Agreed. I would drop that one too.
> 
>> > I thought about extending the folder to at least store the dates; maybe
>> > even the owner and the size should be stored here as well.
>> >
>> > What do you think?
>>
>> Conceptually it's better to keep this on the object, in case it gets
>> moved, right?
> 
> 
> Probably. I think MomentoBags might be the answer (as RDM pointed out), 
> but since I do not know how they work, I am not feeling to0 comfortable 
> with them. I should look into that.

MementoBags indirect the storage of "metadata" for which the object's own
contracts do not take responsibility;  the indirection allows for reuse
in sites with wildly different policies (e.g., some sites might use an
ObjectHub to find the bag;  others might store in a special attribute on
the content object itself;  others might use a relational or LDAP store).
The combination of adapters and MementoBags makes "dumb" content objects
truly possible.


Tres.
-- 
===============================================================
Tres Seaver                                tseaver@zope.com
Zope Corporation      "Zope Dealers"       http://www.zope.com