[Zope3-dev] Re: Object Status Info

[Casey Duncan]

Stephan Richter wrote:
> 
>> > What do you think?
>>
>> I think adapters are the key.  Adapt objects to IFileAccessMode,
>> IOwnership, IGroupOwnership, IObjectSize, and IFileTimes.  (Those names
>> might not be right, but they are a start.)  Perhaps there might even 
>> be an
>> "IUnix_ls" view that looks up those adapters, supplying a default when
>> there is no adapter found.
> 
> 
> First I wanted to reject this idea, since it adds just so many more 
> interfaces, but now I think this might not be a bad idea. This way the 
> VFSFileView (implments IVFSFilePublisher) object can implement all of 
> these interfaces and can be reused for many other things.

Yes, you want to use adapters here. The extra interfaces will actually 
save work and headaches down the line.

For instance, say I have three objects stored in a folder: A File object 
stored in the ZODB, a File reference to a file on the local FS, and a 
file object mapped from an RDBMS.

So long as each of these define the minimal adapters needed, things will 
work. Whether mementos, file system metadata, object attributes or 
relational tables are used to store the data is of no consequence to the 
FTP server code. It just asks for the adapter and lets it sort it out.

Plus, you can also register default adapters for non-essential data. 
Like lets say the object has no notion of file size. So, it define any 
methods or adapters to determine it. The default adapter could just 
always return 0, for instance.

Also, the adapters would be quite useful for the unix file mode 
mappings. They may mean different things for different objects 
(folderish vs non-folderish for instance). Execute on one would be 
different than execute on another. Again, the server won't care because 
it just asks for the adapter. The folderish objects might provide a 
different one than the other objects, instead of the server having to 
sniff for folderishness via some attribute like Zope 2 currently does.

Remember to that many objects will be able to share adapters potentially 
(or subclass existing ones), so the amount of code actually written may 
be smaller in the long run.

As for the modified date, Tres is right that bobobase_m_time, is not the
correct solution. However, I might argue that for now, the default adapter
for getting file date info should use it anyway. Just comment it so that 
we know to go back and come up with a better abstraction. it will work 
fine, and good enough for now. Its not about getting the implementation 
perfect now anyway, getting the components right is more important.

-Casey