savannah-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Savannah-dev] debian packaging and protocol thoughts


From: Roland Mas
Subject: Re: [Savannah-dev] debian packaging and protocol thoughts
Date: Thu, 29 Nov 2001 14:33:40 +0100
User-agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/21.1 (i386-debian-linux-gnu)

Guillaume Morin (2001-11-18 16:30:42 +0100) :

[I'm sorry this email took me so long to write.  I kept rewriting it
under the impression of repeating myself over and over...  If I still
am not clear, I'll try writing it while drunk, maybe it'll help.]

> Dans un message du 16 nov à 18:23, Roland Mas écrivait :
>> Um...  I think I'd need a briefing of what he did before I can try and
>> replace it with something else.  I browsed through my CVS checkout,
>> and I can't find where exactly the communication layer lies.  Feel
>> free to enlighten me.
>
> The communication thing is just a small perl script that "rsync"s XML
> dumps. You can find it in savannah-backend/scripts/common/.
>
> The thing that I do not understand is how CORBA could replace this. Your
> examples are very general and I have difficulties to use them to replace
> rsync if we take for granted that we base the communication on XML dumps
> (which has been discussed and agreed iirc). Could you explain me ?

Well, it's like this.  You have several thingies, and you would like
them to share information, data, whatever.

  Basically, the XML approach is a "stop all, dump all data, transfer
all data, reload all data, restart" approach.  If things are done
right, you can do it without stopping and restarting, but that still
leaves three steps to handle.  That means *plenty* of code to do:
write the XML from the source database, transfer it, then parse it and
transform it into your internal object representation before inserting
it back into the destination database.

  My suggestion (CORBA) limits the amount of code to be written.
Basically, it means that instead of dumping, transferring and
reloading all the data, you update it by an RPC call of the like of
"update this object with these data" (or, "give me the data
corresponding to this object", depending on how you choose to do it).
This can be done either daily for a bunch of objects, or in real-time
(update the mirror object as soon as the main one is changed).

  I suppose you already have an object-oriented model over your
database.  Let's say you have your interface, Group, with one
attribute, a group description.  If you choose the pull method, your
mirror accesses this attribute on the main Group object and updates
its own.  This is exactly one straightforward line of code:
"$localgroup->{desc} = $remotegroup->_get_desc();" in Perl,
"localgroup.desc = remotegroup.desc" in Python, I suspect it's
something along one of those lines in other languages.  The push
method would be "$remotegroup->_set_desc($localgroup->{desc});" in
Perl, "remotegroup.desc = localgroup.desc" in Python.  One line, when
the ORB is initialised (and the sample application I've previously
sent on this list should show that this initialisation is pretty
straightforward).

  At some point, you'll also need to check for return codes, or get
bidirectional communication.  Exceptions.  Inheritance.  Whatever.
Want to hand-code everything in XML?

  I'm not saying that CORBA would solve all problems, obviously.  You
would still have to code the methods, manage permissions, locks and
concurrency, for a start.  But I think for what Savannah aims at
becoming (I seem to remember the word "distributed" in some email or
other), using a hand-coded transmission channel means spending way too
much time and code in doing it, leaving too little for the actual
logic of the application.  I much prefer wrapping my object.method()
in a try...catch block than having to make sure the rsync worked
correctly and the import of the data went OK, and retry everything if
anything failed.  Much better control of your granularity, for one
thing, and no need to hand-code the exception handling.

  On the other hand, even if (as you imply) XML dumps have been chosen
and agreed upon, I think CORBA would provide a better communication
layer than rsync.  It would remove the need for an external program,
for a start, and you could customise error codes and exceptions, add
feedback, logging, whatever.

  Now you do whatever you feel like, of course.  Should you go the
CORBA way, feel free to ask for further advice, I'll be glad to
provide it (as far as I can).

Roland.
-- 
Roland Mas

Why did the tachyon cross the road?
Because it was on the other side.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]