Hi!

 ac> Have any of the SMAPI developers looked at XMSGAPI and 
 ac> considered using it instead of SMAPI?

Perhaps you'd like to explain in short what the main advantages of such a
step would be? I understand that having two concurring msgapi's might
impove development due to concurrency effects, but what was your personal
motivation to start developing a second msgapi?

 ac> Also, can the Husky developers please stop using #include 
 acsmapi/header.hheader.h> and cc 

No. We were at #include  and were forced to change it, as
some of the names SMAPI used for header files clashed with files already
installed in /usr/local/include by different open source packages.

I personally think that #include  is much better - think
of it as a namespace separation approach.

 acpathpath> is where header.h is located.  Otherwise 
 ac> you MUST have a directory named smapi, which can especially be a 
 ac> problem on non-UNIX machines, particularly because you can't use 
 ac> a symlink to the real SMAPI (which might be XMSGAPI).

I can't see why this would be a problem on non-UNIX machines. Just install
XMSGAPI (or only the headers, if you wish) into a directory called smapi.
What's the problem?

I think this inconvenience is rather low as compared to the big
inconvienience you would have when SMAPI would overwrite existing header
files when being installed on UNIX, or mysterious compile errors when the
wrong header file is attracted. Most major UNIX packages (kde, gnome, ...),
i.E. all that install more than one or two header files (and smapi,
unfortunately, installs half a dozen, we never got this sorted out) use
this approach nowadays.

Regards,
Tobias.

--- Msged/MAC 6.1.2