On 4/7/07, Mike Fitzpatrick <mjfitzpatrick-at-gmail.com> wrote:
>
>
>
> > > In this model, clients can determine for themselves how many
> other
> > > apps are available, what their capabilities are, etc.
> >> :
> > Okay, although I'm worried that this could start to needlessly
> > complicate things, I'm really keen to maintain "simple" as the
> > overriding definition of this specification.
>
> The spec *can* remaiin simple in this respect, but we get
> flexibility in how complicated individual clients want to be. A
> number of the msg systems I looked at started by allowing
> both synch/asych delivery and moved strictly to asynch since
> it was more tolerant to failure of apps and the synch behavior
> could be coded if needed.
Hi Mike,
I think this argument is a strong one. Another system I've been looking at
recently is the Google Web Toolkit for creating Ajax applications. Its
designers made a decision to not hide away the asynchrony by providing
synchronous convenience methods for just this reason: the network isn't
reliable. Their argument is that the asynchrony is a fact of dealing with
the network and developers shouldn't be encouraged to take the easy way out.
However, in our case it's not quite so bad since all the apps are on the
desktop we might hope that the system is more reliable and synchronous
behaviour could be allowed. The sort of use case I have in mind for it is
that when an application starts up it might want to message all the other
apps to gather metadata about them (names, descriptions, icons etc) with
which it will populate one of its menus. If I can send a message
synchronously it's much easier to code, and it doesn't really matter if one
of the receiving apps "times out", it will just delay the start up of ours a
little. If we only have asynchronous messaging then either we code some
sort of busy-wait loop waiting for the replies to come in (which doesn't
gain us anything), or we populate the menu dynamically as the replies
arrive. This is certainly do-able and is probably cooler, but it's also
more tricky to code.
My other use case is the python-command-line-sender, who can't receive
messages so can't get info back from the system except by means of
synchronous request-response style messages.
Do any of the Plastic devs have any comments about which style of messaging they use? I tend to use synchronous messaging when the reply is important, but responsiveness isn't (e.g. the metadata gathering case above), and asynchronous when the reply is unimportant but you want to be responsive ( e.g. sending a row subset for an application to highlight).
John Received on 2007-04-07Z12:22:32