Re: Messaging system

[Adrian Ratnapala <s369625@student.uq.edu.au>]

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.
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
the other
hand we can always add this functionallity in later if we think we need it.


One other thing.  As it stands our message implementaion is a standalone "branch" from
the GTK-- version.  I think this is better than  using "real" gtk signals because
I don't
think either of our groups wants to get tied to an almost unrelated project.

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
components of
PPlay should be as indpenedent as possible.   The maker of a Civilization style game
will want to
benefit from our FileIO, GameSpace and AI services, but probably not our graphics ones.
I designed GameSpace with this in mind.   The maker of such a game would want to use a
more
convetional graphics sysbsystem/GUI.   Such for example... GTK.   The benefits of having
compatible
signal systems should be obvious.


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.
This means more complication and work for everyone involved.   On the plus side, I
firmly beleive it is
The Right Thing To Do.

This is because messaging systems can used for so many different things.   We are using
it for GUI and
game logic,  GTK-- is using it for GUI  one other project I know of (the Mnemonic
project) is using very  similar system for communication between seperate,  dynamically
loaded web   browser modules.   If there was a common, free library out there, I would
be useful for all sorts of developers.  Another reason for having a seperat project is
that the design of such a system is not for speedfreak game developers so much as for
people involed in large, really cool object oriented systems (and here I am talking
about big things like CORBA more than our little class library).

Once again the big question is whether it is worth the effort.

Anyway, bye bye.