Re: AW: Commander Activation changes.



"Baulig, ITS P A800, TR" <MartinB2@deutschepost.de> writes:

> Otherwise, I don't see why we need to have factories at all - if we need to
> find & contact the commander's servant anyways
> to get the factory, it can also provide a GNOME::Debugger::Commander::new ()
> method.
Actually, the factory isn't strictly required.  Right now, the code uses
goad_server_activate_with_id() to activate the commander server.  If you
don't want to use a factory, you don't have to.  If you do need a factory, 
you simply implement a GenericFactory, and set up you .gnorba files so that
activating that goad id will go through a factory.  That is what ggdb now 
does.  ggdb happens to need a factory, because starting the gdb-guile server 
takes more effort than some servers (command line options, etc).  But that
gdb-guile specific stuff needed to be pulled out of gnome-debug, and not
used as a generic commander factory, since it had gdb-guile specific code.

> On the other hand, one factory for everything has the advantage that this
> factory is the only thing that needs to deal with the
> .commander files - ideally all clients / GUIs can talk to that factory to
> find & activate a commander.
Clients will need to deal with .commander files anyway, to determine which 
commander they want to use for a given executable.  There's a 
library function in gnome-debug now that returns a list of all the 
registered commanders.

Like I said, the code to locate a commander is like 10 lines.  It takes 
another line or two to call goad_server_activate_with_id() once you find 
the goad id. If we want to put this functionality into a separate factory 
server, we can.  However, it will take more lines of code to setup and 
communicate with that server than to simply search the commander list 
yourself.  I think we would be better served putting that "factory" in a 
library function.  It is *much* more efficient, and easier to manage.  I 
also think we need to avoid using CORBA whenever practical, and it is
practical here.

Cheers,
-dave  






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