This is the mail archive of the mailing list for the Archer project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Froggy planning

I'm far enough along in froggy to start planning for the ultimate user interface, of which I see, at the moment, three possibilities:

The first is a very low level i/f consisting ioctl() operations to the froggy pseudo-file--if you look in froggy-test.c, that's what's there. There are two up-sides of using ioctl()s: it's slightly more efficient than the alternatives, and it's obviously more flexible. The down-sides are that it's harder to code the ioctl()s and, if you do it wrong, you and your app can get very, very, confused. (That's because the data returned to the app from the module is in a streamed header/data format where the length of the header depends on its type and the length of the data is specified in the header--obviously if you don't do the right things with the lengths, things will come unstuck in a hurry. (I could, I suppose, write something that tries to resync out-of-sync streams, but that adds overhead and complexity.))

Option two is to provide a higher level i/f that wraps the ioctl()s in fcn calls in a library (libfroggy or libutrace or something.) That's a good bit safer, of course, mostly because the packet lengths are buried, and the app writer don't have to deal with _IOW macros and the like. The down side is a little loss of efficiency--there shouldn't be much, if any, loss of flexibility--pretty much anything can be added to the API.

A third possibilty comes to mind that's a kind of a superset of option two but, in addition, hides the response thread, or at least more of the messy details in it. Option two would probably provide a wrapper around a blocking read that would return complete, partially decoded, packets and guarantee packet synchronisation, but the loop that fcn is in would be the responsibility of the app writer. Option three might conceptually handle the loop as well, probably with registered callbacks to do whatever needs to be done with any given packet type.

Or any other option people want to propose...

Let me know.

-- Chris Moller

 I know that you believe you understand what you think I said, but
 I'm not sure you realize that what you heard is not what I meant.
     -- Robert McCloskey

Attachment: signature.asc
Description: OpenPGP digital signature

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]