[PEAK] Making PyProtocols work for aeve
Bob Ippolito
bob at redivi.com
Tue Nov 25 10:45:45 EST 2003
I have a project that I'm thinking about using PyProtocols for.
Currently, it's using something conceptually similar that I wrote
myself. The software is aeve, an Apple Events bridge for MacPython.
The way you communicate with the Apple Event subsystem is via this
mostly opaque type called an AEDesc (which is kinda like a PyObject*).
An AEDesc has a 4 character code that represents what it is, and then
some (usually) opaque bytes.
Some AEDescs are simply decoded into Python types, for example lists,
floats, records (like a dict, except the keys are always 4 character
codes), etc. However, some of them represent classes. A class code is
specific to a particular application, not global to the Apple Event
subsystem (as in floats, ints, etc.). So when these are adapted to
Python types (there is a Python "shadow" of the class that mimics all
of the properties, methods, etc) they must be adapted in the context of
the application (or the global context, if not found in the
application). One problem is that you can get these class types inside
container AEDescs, so the adaptation needs to carry around a context
with it.
I've been having the following conceptual issues making this fit into
PyProtocols
1) I really need to adapt by object introspection (The AEDesc.type
four character code), not by type. Everything is an AEDesc on the
incoming side. Right now I'm playing around with the idea that I make
interfaces for every since four character code that I know about, and
an AEDesc wrapper that figures out which interface to use (based upon
the application context) and does adviseObject(self,
provides=(ISomeSpecificFourCharCode,)) in its __init__. This is kinda
ugly.
2) I need adaptation contexts (per bridged application). I don't
really see how the "Extending the Framework for Context" example can
apply to my use case.
3) I need to be able to weight certain adaptations. Some conversions
are lossy (i.e. double -> float), and shouldn't be used unless that's
what's asked for.
4) If you can't find an explicit adaptation path, you can ask the
Apple Event subsystem to (attempt to) coerce it for you. This has the
problem of making way too many adapter declarations.
5) I have a "MetaInterface" .. "convert this AEDesc to something
Pythonic" or "convert this Pythonic thing to an AEDesc". I haven't
quite figured out how best to set that up with PyProtocols. I'm almost
thinking that the four character code interfaces should also be the
adapters to/from the base AEDesc, would that work well with
PyProtocols?
6) A lot of the adaptation is an actual conversion not a wrapping, so
I would prefer to use a non-instantiated class (via classmethods) or
function as the adapter from InterfaceA to InterfaceB. I couldn't
figure that out, it's pretty easy with Twisted's interfaces though.
7) AEDesc has an equivalent to None ('null'). This seems like it
would be awfully hard to return from PyProtocols ;) I don't really
want to have all my interfaces use a getter function just so I can
adapt this type to None!
It sounds almost like I need to write some really custom __conform__
and __adapt__ special methods, so if I have to go that route, what
would using PyProtocols really get me?
Also, are there any relatively complex/large open source projects that
use PyProtocols other than PEAK/PyProtocols? I want to see how other
people are using it, the examples in the PyProtocols documentation seem
to be too trivial to be of much use to me.
-bob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2357 bytes
Desc: not available
Url : http://www.eby-sarna.com/pipermail/peak/attachments/20031125/ebfeca33/smime.bin
More information about the PEAK
mailing list