[hpsdr] Proposal for a new Software project.

[Murray Lang]

Hi Chris,

This is still really a bottom up approach I think. As hams we tend to be 
preoccupied with communications and jump straight into trying to solve 
these technical issues first then work outwards as an afterthought. This 
works, but I think is the reason we still have no application level 
standard after all these years. Obviously we'll get nowhere without 
solving the technical issues, but I think some time should also be set 
aside to contemplate an entirely *abstract* API.

I think such an API would simply describe a collection of appliances 
with a collection of settings. The settings would have a name, a data 
type and a range of valid values. The API would also have to provide a 
means of discovering the available appliances and determining their 
capabilities . At some lower level these would be described by a 
configuration file or service. An interesting question is how you would 
deal with and represent radios with multiple receivers.

With such a standard API available, people talented at user interface 
development could focus entirely on that. How the physical device is 
driven and where it is situated is not relevant. Friendly hard working 
boffins will plug in all those nuts and bolts underneath.

The language used to describe the API is an issue in itself. However I 
think that this doesn't matter much in the early stages - get the 
semantics ironed out in a language of convenience then worry about how 
it might be published.

</2c>
Murray VK6HL

Chris Albertson wrote:
> That is way to low of a level to be worried about now.  What you need
> to thing about first are:
>
> (1) what are the "things" that need to talk and what might they need to say.
>
> (2) are the comunicatins channels one to one.  Or should each object
> listen to whom ever might want to speek.
>
> (3) If an object needs to make a request does it need to know in
> advange who to ask or do we need a kind d directory service.
>
>   

 1259808248.0