Re: component architecture



John> I think where I am not clear on this picture is that somewhere
John> there has to be a bit of code that gets executed when the event
John> for file editing occurs - but where is this code going to be?

In my plan, events are only for notification of state change.  (This
is just a terminology nit.)

When a program (e.g., MC) wants to edit something, it will have to
find the appropriate GnomeEditor (e.g.) object, and then make the edit
request to this edit object.

You can find the editor object using the Trader service (or suitable
analog).  The editor will be magically started if it is not already
running.

John> Or for the example of adding a menu option to the editor, some
John> Corba client script must call that exported method on the editor
John> to add the menu.

John> Does it need to be called every time the editor is started?
John> Does that client script need to be a daemon running that listens
John> for editor_start events, and add the menu when it gets one?

Presumably the editor add-on would register itself once (at install
time).

One way to do this would be to register add-ons in the name service.
At startup the editor would scan part of the name service to find what
it should add to its menus.

Probably there is already a CORBA AddMutatorToMenuService that I don't
know about :-).


The name service would be persistent, so changes would magically stick
around.


John> If you could explain some of the details of how this would work
John> I would appreciate it.  Perhaps the group is tired of my
John> questions and personal email would be better??

I think it's better to discuss these things in the open.  If people
didn't want to hear it, they wouldn't be on the components list.

Tom



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