Re: AW: Commander Activation changes.
- From: Dave Camp <campd oit edu>
- To: Martin Baulig at Home <martin home-of-linux org>
- Cc: gnome-debugger-list gnome org
- Subject: Re: AW: Commander Activation changes.
- Date: 24 Sep 1999 08:11:02 -0700
"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]