Re: Miscellaneous comments and questions

["Sandro Magi" <naasking@hotmail.com> writes:]

>The 'perm' error messages that I sometimes get when working in VSTa were
>just frustrating.

Note that some of this went away recently, when I removed some non-portable
decoding of return status and used the appropriate wait.h macros.

>Add the fact that I have nowhere to check for command
>options

Except the source. :->

>and that their are few man pages

Guilty as charged. It's just that I thought the truly VSTa unique stuff
would need documenting before things which behaved much like any other UNIX
would.

>(and the fact that the mailing list
>archives are not searchable) and I'm forced to post the most trivial
>questions to this list(like my very simple question a few months ago about
>starting the mouse server).

Not that it's a problem to ask!

But I wouldn't mind having the archives searchable. I thought some of the
search engines could actually do that (search within a given WWW domain
only)--I know our mail archives are picked up by a couple of the big search
engines.

Or if somebody has a good utility I could attach to CGI, I'd be happy to
look into it.

>GNU utilities have a --help option that (usually) self documents the use of
>that command. I was thinking something along those lines would be really
>helpful. --help could list options available, very brief summary of the
>options and other relevant parameters.

I've also been wondering if we shouldn't head off the well-beaten UNIX track
and do a Tenex-style UI instead? Still with distinct utilities in their own
processes beneath, but with command completion and context sensitive help
integrated.

>Adding a --help option would probably also reduce the number of simple and
>repeat questions on the mailing list.

I really don't remember that many of these, as opposed to stuff which runs
deeper and is more unique to VSTa. But I agree the mouse server could be a
little more helpful.

>Why not just have the driver/servers themselves register generic interface
>names? Instead of 'net/ne2000' (or something similar), register 'net/eth0'
>as the first network card, 'net/eth1' as the second, etc.

How does the first know it's supposed to be first? Also, this isn't at all
what a UNIX-ish environment does (not that this is a guarantee that it's the
right way to go).

>A simple loop while registering a name for the server would simplify things
>greatly for ka9q(in semi-pseudo code):
>char *name = "net/eth0";
>n = strlen(name)-1;
>while(name[n] <= '9') {
> /* attempt to register name here, if successful, break */
> name[n]++;
>}
>printf("registered: %s\n",name);

Well, that would *find* them, but in pretty much every IP network I've ever
used you need to relate a deterministic IP address and netmask to the
physical interface.

>Something similar to this would enable ka9q(or any other applications) to
>use the drivers by just looking up the generic names instead of having to
>know the name of the actual driver. Just a thought. :-)

I'm open to suggestions, but in even non-UNIX environments (like, say, IOS)
you want to name a specific physical interface, because there's a specific
physical network attached to it.

Andy Valencia
Received on Fri Feb 16 14:04:43 2001