-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Fri, 3 Feb 2006, Lalo Martins wrote:
I have a semi-functional extension for "server-side" python scripting.
You can `bzr get` it from http://lalo.revisioncontrol.net/bzr/vos-python/
Okay, by publishing some VOS code via bzr you've finally convinced me to
try it out :-)
Conclusion: yes, this is an improvement over cvs/svn. I will probably see
about into converting the repository over to bzr after the 0.23 release.
By semi-functional I mean:
- You can run python code that interacts with vobjects and messages,
from C++
- You can't yet store such python code on a Property
- You can read such code from a file or string
- You can't yet set up such code to handle a message for you (unless you
hack vos)
Okay, looking this over briefly, correct me if I am wrong but it appears
that you are binding VOS into Python by hand, rather than using the
existing work with SWIG. Is there a particular reason for this?
Incidentally, while I'm not sure if message dispatch works in the SWIG
bindings either, other sorts of callbacks (listener notifications) have
been implemented. Adding message handling wouldn't really be that hard.
The last point merits discussion. Pasting from IRC:
(08:13:27) lalo: I have an API question/request
(08:14:38) lalo: how come we have a public, subclassable MessageDispatch
abstract class, and the message handlers are stored in a list of
pointers to this abstract class...
(08:15:27) lalo: *but*, the list itself is private, and there are no
public methods that allow you to use any other kind of message dispatch
The MessageDispatch abstract class is basically a delegate mechanism.
Because C++ is strongly typed (which may be an odd concept if you've been
working in Python too much :-), the message handler has to be a template
class parameterized on the type of object to call back, so the template
classes need a common base so that the container list is typesafe.
Confused yet? :-)
With regards to adding a new method on VobjectBase to add MessageDispatch
objects directly -- yes, that might be a reasonable solution to the
problem you pose. Another solution, one that wouldn't involve changing
the API, would be for your code to register each message call back to call
the same method, and then have that method do a second-stage table lookup
on the message method to dispatch into the python code. Since you're
crossing the language barrier anyway, such an extra step seems reasonable.
I should mention that the message dispatch system is slated to be changed
at some point. Currently the dispatch table is created in the constructor
and duplicated on every single Vobject. This was convenient for the
initial implementation, but is now known to add significant per-object
overhead in terms of initial construction time and overall memory
footprint. Probably what will happen is a hybrid design that provides for
shared/static dispatch tables to eliminate the overhead in C++ classes,
and maintain the option of dynamic tables for Python.
[ Peter Amstutz ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ]
[Lead Programmer][Interreality Project][Virtual Reality for the Internet]
[ VOS: Next Generation Internet Communication][ http://interreality.org ]
[ http://interreality.org/~tetron ][ pgpkey: pgpkeys.mit.edu 18C21DF7 ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFD5utGaeHUyhjCHfcRAujGAJ9WVnIPNBWam6KMPxofEGytLUheNACfXbJL
yNbU7zgOZkmCpRZZAP8Dfqc=
=7AGP
-----END PGP SIGNATURE-----
_______________________________________________
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
