[hpsdr] Proposal for a new Software project.

[Murray Lang]

Hi John,

Web services (http://en.wikipedia.org/wiki/Web_service) spring to mind 
first up. The nice thing about them is that your API is defined  in a 
language-and-platform-neutral text file (WSDL). There are utilities that 
read these files to generate proxies that can be incorporated into your 
client program. The WSDL file also separates API definitions form 
transport binding definitions, and tools such as Web Services Invocation 
Framework (http://ws.apache.org/wsif/) exploit this to plug in various 
transports underneath, including direct linking to code.

How you associate such services to media streaming is a custom job I 
think. However, before going straight into low level socket programming 
for media streaming , have a look at what's already out there (eg 
http://en.wikipedia.org/wiki/Streaming_media http://osflash.org/red5 
etc). Obviously whatever encoding is used will have to be lossless and 
this might limit the options.

Back to the command interface, there are other possibilities as well 
such as Message Queuing (eg ActiveMQ, MSMQ, JMS, AMS etc). Frank 
mentioned XMPP, which was first developed for the Jabber project, which 
is an instant messaging framework. It is likely that the data passed 
through these channels would be XML. This has exciting possibilities 
because a command structure defined in XML would have wide application. 
Also, being text means that endian issues go away. The messy part about 
using MQ however is that replies to commands have to be returned through 
a completely separate message queue. This is a can of worms.

You might also want to consider .NETs WCF Windows Communication 
Foundation. Thanks to the open source MONO project, this approach 
doesn't necessarily tie you to Microsoft and Intel. It would blend in 
nicely with the work done on KISS Konsole.

Other outside possibilities are MODBUS and SNMP, but I don't think these 
would scale very well.

73,
Murray VK6HL

John Melton wrote:
> On 12/01/09 15:58, Murray Lang wrote:
>
>>
>> As for the command channel, there are lots of standards to choose 
>> from that avoid the need for proprietary IP socket stuff.
>>
>
> I am not aware of any standards that support connecting to remote 
> receiver I/Q data streams and setting their frequency, etc.
>
> -- John g0orx/n6lyt
>


 1259803309.0