On Sat, 19 Feb 2005 18:40, James Mastros wrote: > (The other way of doing this is to have an API to find out the > limitations of the device, and simply error if the device-independent > program requests something of the device it cannot handle. This isn't > as good, because it means that users have to do more to write portable > programs, which should be made as easy as possible. Also, it isn't
I don't think having the lower layer try and second guess what the application meant is a good idea. If the lower layer starts out with a way to describe its functionality to the upper layer then application coders will be used to it. > always easy, or even possible, to describe the limitations of a given > device -- sometimes, the only way to tell is to ask the device, and see > if it errors, or the limitations are known, but not simple to describe.) I don't think it's easy but it can certainly be possible. It should be possible to provide an algorithmic description of the restrictions of a given parameter. We use a limited form of this in a work application (eg "must be a power of 2", "must be even" etc..). This would also provide a better user interface I think. Perhaps a compromise would be to be able to set a laxity flag that would allow the lower layer to be able to alter the request and then the application can check it and see if it is acceptable. At least then if the application coder set its they can't complain too loudly ;) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
pgp7u5fWG0i6R.pgp
Description: PGP signature
_______________________________________________ Discuss-gnuradio mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
