> right, it will not be used to get the system working. However it is nice
> to be able for clients to query what sort of configuration the system
> currently has. See xdpyinfo, xinput, and friends.
Sure. How often do you use them and for what purpose ? Ask a normal user
what they do ... most won't know.
It's debugging stuff, and if you need it, you can tune up LibGGI debugging
or similar stuff or talk to the device.
> now consider the user wanting to configure (graphically, with all kinds of
> other jazz...) his windowing system, i.e. setting up the kind of event
> types he wants to use, i.e. the sensitivity of the stylus, etc.
Look at LibGIC. It does just that. And I do not see, why the user has an
advantage of seeing that the device he wants to use as a mouse is a
"Wacom Intuos 1234 Tablet, Revision 567, Firmware-Rev 89,
lefthanded-Stylus-option-installed, with-bumpy-surface-option-installed"
instead of "Wacom Intuos 1234 Tablet".
The additional info is not needed - on the contrary - for an average user it
is probably rather confusing.
> Do you really expect him to mess with the low level stuff like 'origin'
> etc. ?
No. I expect him to mess with a nice and simple device name.
> I'd rather try to insulate that stuff from the user, letting him deal with
> more descriptive information.
Yes - see above.
> right, and the problem I pointed out is still there: a potential buffer
> overflow for long 'contents'.
Do you _really_ think that this is a problem _in_practice_ ? From an
academic point of view, it surely is, but ...
If you really think it is a problem, you can use something like:
char varname[some_fixed_size];
int varnamestart;
char content[some_fixed_size];
int contentstart;
and iterate querying for more input by raising varnamestart and/or
contentstart. It's not efficient, but as you said - it is used rarely, so
performance is no issue.
> indeed. But I doubt that for this kind of information we really want an
> asynchronous API. These metadata are usually queried once (either at
> startup or whenever a new device is plugged in), and then dealt with by
> the high level layers.
And how do we get them through e.g. the tcp-event-bridge ? By adding an
extra metadata connection ?
> The same would be true for my proposed dictionary. It would be associated
> with a device, so memory management shouldn't be an issue.
Across process boundaries ?
> > Events are not objects like in an OOP language. The point is, that if
> > you want to be able to ignore unknown stuff, you need a generic way to
> > free it.
> <rant>
> I sometimes really wonder why people still consider C such a wonderful tool.
> You'd never have such trouble in C++.
> </rant>
You have, trust me. If you don't have the object definitions at compile time
and thus have code in your executable to deal with the new object, you are
screwed, if you receive it from somewhere, like from an external source.
> > start with that nice and simple approach and later add lots of cruft to it
> > to make a few people happy, please have a look at the specs of DICOM
> if you start with a 'nice and simple' model which doesn't scale
It does. All the braindamage added to it, could have been done within the
model and could have been done efficiently.
Let me outline the problem:
The basic idea was to have an event-like protocol like the gii events, i.e.
something that starts out with a type and a length and when you dont know
what the type means, you jump by length bytes and are still happy.
Now the stuff added were:
There was another similar older format that had other positions for this
data. Instead of just marking a new style stream as such, they allowed the
file to be in any of both formats and placed the decision in the "format
negotiation", which is lost when such a file leaves a DICOM database.
Moreover a third variant exists, which is dependent on the type value
being within a certain set, which has yet another overlap in the arrangement
of type and value code.
To make it a really nice challenge to get a reliable reader done,
it seems to be allowed (though the standard is unclear about it, but
many existing apps do it) to mix both formats. My reader makes
heuristic decisions about reasonable field lengths to get around that.
Someone added "variable length records", which is pure nonsense, as they
contain ffff as length marker to say that it is var length, but then contain
an "internal" stream of fields that do have length info and are terminated
with yet another specialcased EndOfSubstream record.
This could have been added transparently by just putting the real length of
the "var length record header" (which is constant) in there as well as in
the EOS record header. The reader would then just have stepped through the
"variable length" sub-data without even noticing that it is sub-data.
> (you call it 'making a few people happy', I call it flexibility),
I can send you the code of the reader. You'll probably understand what I
mean, then.
> Seriously, I don't see a big deal in adding a simple function to query
> (synchronously, much like the giiQueryDeviceInfoByNumber() function you
> pointed out) that returns heap allocated data (with clear ownership
> semantics !) with additional information that can't be obtained with
> events.
See above. It ruins the possibility to tunnel this info through a stream.
> My proposal is to add a synchronous* interface to GII to let users query
> device information. That would (IMO) even render the current command
> events obsolete.
If you find a good solution that will keep the stuff stream-transparent,
o.k. - otherwise I don't think it is worth the small gain.
The command events were created for exactly the purpose of keeping
everything transparent, even across processes and towards kernel drivers.
CU, Andy
--
= Andreas Beck | Email : <[EMAIL PROTECTED]> =
