Various approaches to using the Zephyr Notification System from python.
After ignoring the zephyr code for a while (the logger has Just Worked
for rather a while, barring network outages, and it restarts well
enough after those) I took another look at ctypes. One key difference
is that pyrex imports the abstract (as much as C ever is) structure
definitions... so you can define fields by name based on what's
visible and part of the API... because under the covers it is
compiling against the header files; with ctypes, you have to duplicate
the physical C structure, because it isn't compiling at all, just
building up the same thing in memory.
Given that, it still only took 95 lines of code to cook up the notice type, initialize one, and send it (unauthenticated). I still need to wrap it up in a more useful interface, but this convinces me that it works for a library like this... next step is authentication, and then maybe gssapi...
Should have tried pyrex sooner - 56 lines later, I have something that
sends minimally. Another line on top of that and it has signatures,
so that tzc doesn't get twitchy. Should figure out if it really needs
to use strdup (and a destructor) or if strings are procesed correctly.
sending to <open file 'zlogs/krb5@ATHENA.MIT.EDU', mode 'a' at 0x828a360>
Traceback (most recent call last):
File "zlogger.py", line 158, in ?
run(60*60, helper)
File "zlogger.py", line 105, in run
logsub(zport, classfile, instfile)
File "zlogger.py", line 71, in logsub
zzz2.Subscription(r, c, i).sub(zport)
File "/rooftop/eichin/thok/intranet/python/zephyr/zzz.pyx", line 182, in zzz.CSubscription.sub
raise ComErrException(error_message(ret))
__main__.ComErrException: Kerberos error: Protocol Error
kitten-that-lurks-above$ . HOWTO
('*', 'zsex@ATHENA.MIT.EDU', '*')
Z: zlogs/zsex@ATHENA.MIT.EDU ['*@ATHENA.MIT.EDU', 'zsex', '*', 'zlogs/zsex@ATHENA.MIT.EDU']Think about using pyrex too?
Merry Xmas! Work is almost caught up, Chocolate production is caught up. Time to catch up on python projects.
Now that I "get" the class construction technique, it's time to think about how applications are going to use this library, and actually design the classes (instead of just trying to build it up from the library.)
Trying again with http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/54352 approach.
Took a shortcut and implemented Notice_send outright. Still need an
explicit dictionary to make it accessible.
Idle too long, poking at it again just to get if off my plate (given
the success of one-day projects like handrss.py, I should be able to
do the same here, and this is something I'd use daily...)
Note that structurally, I'd like to put as much in python as makes sense, without contortion; so, the library should handle authenticators, at least at this stage, but maybe the upper level code should handle sending packets. Given how well the perl code worked, though, using struct for the packing may not be unreasonable, as long as I can be sure that the interface is nonetheless covered.
http://starship.python.net/crew/arcege/extwriting/pyext.html
Poking at it again. Got Notice as a subtype (by putting Notice_alloc
in ZephyrMethods, which makes sense in retrospect.) Next would be to
figure out what to do about message string lists, and the auth field.
After a few days experience with unittest/PyUnit on bbr-dev, tossed together testzephyr.py as a place to hang tests as it grows, and maybe before it grows (mmm, TDD.)
I did find geek@cmu.edu's "Zephyr 6.1" python bindings and
gui client, but it puts far more in the C code than I would, as well
not exposing Notice as a python class. This is probably because it
was written for a much older python.
This started as an excercise in learning how to import C libraries
into python modules. As such, I should duplicate it with pyrex at
some point, for comparison, as it would be much cleaner. Once the
module exists, a new zephyr logger (replacing the Ada one) and a tzc
clone are both good things to write with it.