Re: Bonobo Unique Application v3.1

["Gustavo J. A. M. Carneiro" <gjc inescporto pt>]

A Ter, 2003-04-22 às 10:26, Michael Meeks escreveu:

> 	I'd also like to get most of the nice signal stuff into CVS in a more
> generic form as well, which looks like it could be generally useful. I
> was envisaging that the 'getMessages' thing would return a
> sequence<SignalDescription>:
> 
> struct SignalDescription {
> 	string name;
> 	Any    retval;
> 	Any    params;
> 	long   flags;
> };
> 
> 	And that we could build this out of: g_signal_list_ids, and a
> g_signal_query on the remove GObject; this would then allow us to
> introspet / invoke arbitrary signals on remote objects - which would be
> a very nice feature - which we could then re-use inside libbonobo. Would
> you be interested in splitting that functionality out into a
> 'BonoboSignalServer/BonoboSignalClient' object pair ? [ as a future
> extension, we could (most likely) hook things up so we could
> g_signal_emit on the client without a special method [ your argv /
> collection thing looks great for now ], and it would 'just work' ;-].

  Just so I understand your idea, BonoboSignalServer would replace
BonoboApplication and BonoboSignalClient would replace BonoboAppClient?

  I get the impression that with your approach the message sending
interface would get more complicated.  You would have to register 
signals for each message type you want to send, and g_signal_new is not
trivial, plus you need to generate C marshallers, which implies adding
stuff to the makefile, etc., and people seem to not like this sort of
thing very much.  g_signal_emit is not elegant either.  Are you sure
this signal stuff is recommended?  The existing API is more
programmer-friendly, IMHO.  I think people want a more runtime oriented
and simple message API.  For real typesafe and elegant message passing,
we already have CORBA. :)

> 
> 	How does that sound ? either way, we should get as much as we can of
> what you've done in now I think.

  Sounds good (except for my worries regarding increased API
complexity), but I need to understant it first! :)

  Bye.
-- 
Gustavo João Alves Marques Carneiro
<gjc inescporto pt> <gustavo users sourceforge net>