[TransWarp] peak.naming .. first contact
ueck at net-labs.de
Fri Feb 14 16:56:12 EST 2003
--On Freitag, 14. Februar 2003 15:35 -0500 "Phillip J. Eby" <pje at telecommunity.com> wrote:
> This is the weak point in the current interfaces and base classes. I'll consider patches for this. :)
if my time allows i'll try to contribute (but let me first understand what happens before i make
any proposals on this ;-)
> If you look at the peak.naming.interfaces, IReadContext and IWriteContext have comments like this:
> # XXX search, getAttributes
> # XXX modifyAttributes
> These methods should probably be defined in the interfaces, and some support for this added to the context base
> classes. I haven't yet encountered a situation where I actually need these, so I've left them unspecified. If you
> can describe your use cases, maybe I can see how they should be fleshed out.
in the case of imap-folder i'ld need to access two attributes:
- ACL: IMAP-ACL's are basically a list of tuples [('user', 'rights',), (...),]
that are managed in my current implementation through a customized model.Collection.
- Flags: Flags is a list of Names e.g. 'Marked','Noselect' that can be read for each folder.
one could use it like this (just a tiny draft):
folder = naming.lookup('imap://user:firstname.lastname@example.org/INBOX.path.to.folder')
acl = folder.getAttribute('acl')
acl['someotheruser'] = 'lrwpicdsa'
the underlying ContextImplementation would need to know how to handle these Attributes.
In case of an LDAP-Context this could be very usefull as well, cause any object
can have children and attributes at the same time.
> That's basically correct. I assume that MyFolderQuery is a QueryDM that takes a tuple containing a folder path as
> an object ID. You would implement that QueryDM by having its '_load()' method return a sequence of folders, and
> keeping the default QueryDM defaultClass of 'PersistentQuery'. So you don't have to implement a "list-like
> interface" if you don't want to. PersistentQuery and QueryLink will take care of this for you.
i did this and it worked out well .. but
> However, that all assumes that the 'folders' collection isn't the end of the relationship that you manipulate in your
> underlying storage. If you want to have your '_save()' routine look at this list to decide what to add, then this is
> not the way to do it (the QueryLink should be on the "parent" pointer side of the relationship). If your '_save()'
> routine instead looks at what the parent folder of this folder is in order to figure out what to add it to, then you
> should use the approach you've described here.
you hit the point :)
of course one should be able to add Folders to the collection and _save() them.
i'm not 100% clear about your description with the relationships.
what do you mean by "the QueryLink should be on the "parent" pointer side of the relationship" ??
how would one basically setup the relations to be able to use model.Collection/Sequence fields
together with DataManagers ?
in the old TW.Database i did manual querying and updates on the DM from within the features
i'ld like to be able to do something like this:
# setup stuff to use IMAP_DM
# retrieve folder and use it
folder = IMAP_DM['INBOX.test']
<prints out a list of instances of child-folders>
[('test1', 'lrpwicdsa',), ('test2', 'lrwpicdsa',)]
# modify folder
# an acl may get an object as well .. don't know yet.
# create a subfolder
# this below is not mandatory if there is a cleaner way to do
new_folder = IMAPFolder(IMAP_DM, componentName='sub01')
# storing stuff on commit
# an imap-connection is not really transactional
# so it may not make sense - does it ??
that commit would do the following:
- store the modified acls for folder
- use folder.path + [new_folder.getComponentName()] as imapFolderPath
in this case: 'INBOX.test.sub01'
and create the subfolder in the imap-server and set's acls like defined
for the ACL set/get it's fairly easy to fetch them at <dm>._load() time
and store them when _save() is called.
how should this be done for subfolders ??
thanks for your advice
net-labs Systemhaus GmbH
Ebersberger Str. 46
85570 Markt Schwaben
email: ueck at net-labs.de
More information about the PEAK