[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] gnuradio interface cleanup

From: Daniel O'Connor
Subject: Re: [Discuss-gnuradio] gnuradio interface cleanup
Date: Sat, 19 Feb 2005 23:50:44 +1030
User-agent: KMail/1.7.92

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 

> 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

Attachment: pgpohpZ73lm4k.pgp
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]