Re: Thoughts for discussion & info request

> 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

I strongly agree.

> 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...

Too.

>
> 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?
>

Damned. a couple of minitues ago it answerd Dave, because his reply
arrived earlier by email. Dave, please forward it.

I strongly agree. The fact is that a historical accident lead to a
server ruled naming. What is needed is to make the name associated
with an INSTANCE of anything, not with it CLASS. Moreover, the name
must depend on the user (client) of the name, not oon the use object.

For the last issue: Why can't you have the name of the config file
given at startup time (on the command line) or mount the name of
$HOME/.madorc to the file you like.
(UHH, know I may have viiolated the terms of VSTa, but that is what I
think it should go.)

/joerg
Received on Tue Aug 16 04:09:16 1994