Re: Thoughts for discussion & info request

>in the drive. It's exactly this sort of flexibility in server coding that
>makes me prefer VSTa to say Unix (although it did take me a couple of months
>to appreciate the benefits).

This, and the fact that servers and the kernel are entirely seperate,
were two of the major reasons I dropped Linux/Unix hacking in favor of
VSTa. However, I am a little worried that there is no overall
structure to the naming policy as yet. As Dave has noted, the naming
policy has tended to evolve based on server needs. This is good in
that the application is driving the implementation do a degree (so we
don't end up with theoretically nice, but realistically unusable
systems). I wonder if we have evolved enough to try to start deciding
on some guidelines/conventions?

Once I get back into mainstream VSTa hacking again, I'd like to
explore this issue. I remain unconvinced that the way things are being
done now is necessarily the best. I am biased toward an object based
approach...

BTW. One problem I can still see is something like MADO which cannot
assume a fixed file system structure, but for which configuration
information should be specifiable by the user (ie. It'd be nice to
always assume a ~/.madorc, but I can't). Has anyone thought of beefing
up the environment server, or writing something similar, to handle
configuration data?
Received on Mon Aug 15 05:16:59 1994