Re: Messaging system

[Christian Reiniger <warewolf@mayn.de>]

Adrian Ratnapala wrote:

>Christian Reiniger wrote:
>
>> Hi,
>>
>> Just some notes from me...
>>
>> >Their concern was that message receivers had to inherit from the class
>> >ppMessageReceiver, or something
>> >like that.  The writer pointed to a document discussing this issue.
>>
>> [...]
>> >The requirement that a receiver derive from ppMessageReceiver is due to
>> >an added
>> >feature we have,  that is, when a receiver is destroyed, the connection
>> >between it and the
>> >sender is automatically destroyed.
>> >
>> >If we went without this feature we could get some lovely flexibilty.
>> >Any member of any C++
>> >class, or even just straight C functions could be used as message
>> >receivers without having to be
>> >modified or wrapped.   It would not be  difficult to add this
>> >functionality to the existing system
>> >anyway,  the question is whether it is worth it.
>>
>> Actually we already can connect to plain C functions (have a look at the
>> ppConnectToFunction calls). For standalone functions the mechanism
>> described above isnīt implemented, because functions usually are
>> not dynamically allocated ;)
>>
>> So the ppMessageReceiver problem is only present if we have methods
>> as target. And this only poses a problem if the receiving object is part of some
>> code that may not be modified. This should be really (!!) uncommon.
>>
>> If someone wants to have some non-PPlay class as receiver in his own
>> program she just had to inherit her own version from ppMessageReceiver
>> - that usually doesnīt matter.
>>
>> I think the added comfort (and robustness!!) of the current version is worth
>> the little inconvenience (As long as we donīt know a really better solution ;).
>

>As you say tradeoff between convenience and flexibility against robustness.  In general
>I prefer tolet application developers make the choice, and hence we should support both
>systems.

Hmm, this would mean making special versions of the ppMsgConnectToMethod () functions with this feature disabled. Or having some extra parameter.

>On the other hand the whole situation is  very uncommon, and I know I would almost
>always
>pick robustness.  So I don't think it would be worth changing the existing system.   On

Does anyone here know a situation where it is difficult or impossible to derive the receiving object from ppMessageBase?

>hand we can always add this functionallity in later if we think we need it.

As adding this functionality would alter the specified behavior (programmers have to be able to rely on this behavior) Iīd think thrice before doing this.

>One the other hand there are benefits of sticking with GTK--.  For one thing,
>developments by
>one group benefits the other.  Another is this,  I envisage that the different

I currently try to synchronize all changes with the Gtk-- team, so both systems will have the same behavior, same features, same handling
- just different naming schemes. I think this is a good solution.

>convetional graphics sysbsystem/GUI.   Such for example... GTK.   The benefits of having
>compatible
>signal systems should be obvious.

It should be trivial to interface our system with the Gtk+ / Gtk-- ones.

>One approach is to create a new microproject  to develop  a GTK compatible C++ template
>library
>for sending messages about.  This library would try to trancend GUI and GTK, but remain
>compatible
>with GTK signals.  This could be started by members of our group as well as the GTK--
>people.

Gtk-- contains an interface between Gtk-- and Gtk+ signals. As our system is identical to the Gtk-- one we can use this almost directly.

>This means more complication and work for everyone involved.   On the plus side, I

Well, itīs about 1-2 hours of work adapting the Gtk-- interface layer and from time to time some syncing work. Thatīs not too much ;)

>project) is using very  similar system for communication between seperate,  dynamically
>loaded web   browser modules. 

This looks more like some CORBA application....

>If there was a common, free library out there, I would

It definitely is a neat idea. I love it. A bit like a mini-CORBA, having PPlay monsters interface to Gtk gauges etc.
Neat.

Cu
	Christian