Froggy planning

[Chris Moller <cmoller at redhat dot com>]

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