"Brian S. Julin" wrote:
>
> On Wed, 27 Jun 2001, Stefan Seefeld wrote:
> > > > I guess a more flexible scheme would be a dictionary of name/value pairs,
> > > > both dynamically allocated strings. Is there any way to add that to GII ?
>
> > I don't see how a single long (parsable) string would solve any of the
> > problems. Given that it would be an (untyped) list of pairs of strings,
> > you can print that out (may be with a little helper function) without
> > caring what these strings contain. But when you care, i.e. when you want
> > to know the version string, you would in your case need to parse the
> > whole string, while in my case you simply look for a pair where the first
> > member is "version". Or did I miss something ?
>
> I don't get what you mean by having a pair of strings; I was thinking just
> one string.
well, the metadata, or the meta-metadata :)
each string has some meaning, such as 'vendor', 'version', 'device name'.
If the set of possible strings is fixed, we could hardcode it:
struct info
{
char *name;
char *vendor;
char *version;
};
but if (and that is a real question) we don't know what kind of information
to store, we have to do it more dynamic, i.e. associate the meaning to the
strings at runtime...
> I believe the strings given by the evdev driver are pulled out of the device
> firmware, at least for USB. Also, just because the evdev (==USB right now
> on Linux) API has a driver name, a device name, and a vendor name does not
> mean all LibGII input targets will have these three values. They may have
> more, in fact, like, for example, a locale code. By using/parsing a string,
precisely, you are making my point.
> we have a solution that will always extract the correct field, and when joe
> user goes to MediaPlay and buys his "PowerSandle" in May of 2006, the crusty
> old installed-from-CD libc7 RedHat version of LibGII he has on his computer
> will allow an app to say:
>
> "Found Input Device: PowerSandle v3.2, (Logitech) 6 axis, 0 buttons"
> even though the PowerSandle didn't exist when it was compiled.
that's exact what I'm aiming at, you are (again) making my point.
> Now, an app that wanted to know the version, would call an API
> function giiExtractVersion(str) to get the version string out. Versions,
> BTW have to be strings because not everyone uses the same notations.
> If we cleverly choose the format of the string, we should be able to
> make escape characters rarely needed.
and why do you want to force everything into a single string that then has to
be parsed to get back to the original tokens ?
> The main problem though, is that there is likely a reason why fixed size
> was used. We need to carefully review the implications of adding a
> variably sized event; at minimum I anticipate we will need to malloc
> the event and the string in the same inscestuous structure such that
> nothing leaks if you just free the event.
sure. Strings are null terminated, and the dictionary itself is, too.
Nothing special about that. A cleanup handler is easily written.
Regards,
Stefan
