Applications Messaging Standard

[John Taylor]

On 15 Feb 2007, at 21:07, Doug Tody wrote:

> On Thu, 15 Feb 2007, John Taylor wrote:
>
>> Hi Doug,
>> Sorry if my terminology clouded the issue,  though I do believe  
>> this is an issue of user-friendliness.
>> As I see it, either the messaging infrastructure always sits at a  
>> known location, or its connection info must be made known to any  
>> clients.
>
> Or both; see for example my recent mail in reply to Mark.
>
> Files are fine for persistent storage or for configuration info  
> such as
> saving user preferences, but are lousy for interprocess communication.

Calling it interprocess communication is making it sound grander than  
it is (although it may be literally true).   Only one process will  
ever write data, and it's a once-per-session occurrence.  We've been  
using this system for over a year now in PLASTIC, and double that in  
the AstroRuntime without any significant problems beyond the odd  
orphaned file.


> IP (sockets) on the other hand, were designed for this purpose.
> A simple solution is to provide a well-known port for discovery
> (basically just a simple keyword-value cache; back it up with an
> environment variable or whatever to config the address)), and hand-off
> to dynamically allocated ports for session stuff.  This can all be  
> done
> at the protocol level without an API, is universally available, and is
> really not much more complex than using a file.  Probably less  
> complex,
> when you consider the subtle issues that files have for this purpose.

I'd be interested to know how much easier or harder it would be to  
use IP from relatively primitive programming environments such as IDL  
(that's not a slur on IDL...it's very sophisticated in other ways).   
One question I have is what would happen on a multiuser machine?   
Would you need some system process running on the one shared well- 
known port?



>
> Ultimately you probably need both: IP for interprocess communication,
> and files (or possibly the registry on a Windows platform) for
> configuration and saving user preferences.

Saving user prefs is possibly a separate issue as they don't  
(usually) have to be shared between unrelated apps so it's entirely  
down to the application author how best to do that.  Woe betide them  
if they store large config files in ~tony.

John




>
> 	- Doug