Agreed. Ed W2RF
-----Original Message----- From: Flexedge [mailto:[email protected]] On Behalf Of David Kjellquist Sent: Monday, November 12, 2012 6:27 PM To: [email protected] Cc: [email protected] Subject: Re: [FlexEdge] Flex 6000 API Thanks for the reply Steve. "What is it about RESTful that you find so compelling?" From a client/developer perspective, it'sthe simplicity and language independence. Under Python (other languages are similar) with a single convenient GET or POST commands are sent and info read. Web services being so universal all the underlying details are taken careful. It also can be independent of location etc. Of course, these same advantages can be built into almost any API, so without seeing the actual Flex API (and under lying data structures) I'm not going to pre-judge. I know you'll take advantage of existing standards. This particularly, "The API is simple, efficient and unencumbered by XML DTDs and self-describing data.", sounds great. "How would you suggest handling asynchronous data under such an interface?" Actually I //wouldn't try to use a simple RESTful client in a synchronous mode as a replacement for SmartSDR. I was really thinking (not all the way through) of a subset of the Flex controls. In such cases asynchronous data would be acceptable. This means a hybrid model, ugh! Finally, let me put me 2 cents in for Flex releasing the API but retaining control. This approach can be nothing but good business for Flex. The ability to harness the "bazaar" rather then the "cathedral" has proven over and over to be a money making model. On 11/12/2012 3:00 PM, Stephen Hicks, N5AC wrote: > The API is well under way. We do plan on making the API available in > some form at a later date, but the terms of this have not yet been > decided. A RESTful interface is not well suited to the API's needs > and adds a lot of unnecessary software construction burden. The API > is simple, efficient and unencumbered by XML DTDs and self-describing > data. > > What is it about RESTful that you find so compelling? How would you > suggest handling asynchronous data under such an interface? > > Steve > > Stephen Hicks, N5AC, AAR6AM > VP Engineering > FlexRadio SystemsT > 4616 W Howard Ln Ste 1-150 > Austin, TX 78728 > Phone: 512-535-4713 x205 > Email: [email protected] <mailto:[email protected]> > Web: www.flexradio.com <http://www.flexradio.com/> Click Here for PGP > Public Key > <https://sites.google.com/a/flex-radio.com/pgp-public-keys/n5ac> > > > > /Tune In ExcitementT/ > PowerSDRT is a trademark of FlexRadio Systems > > > > On Mon, Nov 12, 2012 at 8:42 AM, David Kjellquist <[email protected] > <mailto:[email protected]>> wrote: > > Does anyone know if when the 6000 Series is available will there > be a RESTful > interface? > > I'm developing an automatic antenna switch based on the Raspberry > Pi. RPi > already has a RESTful interface using PYTHON well underway. > > It would be very useful if the antenna switch client and/or > Raspberry PI switch > could obtain band/frequency information from a 6000 via a REST > query to control > antenna switching > > Dave WB5NHL > > _______________________________________________ > Flexedge mailing list > [email protected] <mailto:[email protected]> > http://mail.flex-radio.biz/mailman/listinfo/flexedge_flex-radio.biz > This is the FlexRadio Systems e-mail Reflector called FlexEdge. > It is used for posting topics related to SDR software innovation > and other technical SDR topics. > > _______________________________________________ Flexedge mailing list [email protected] http://mail.flex-radio.biz/mailman/listinfo/flexedge_flex-radio.biz This is the FlexRadio Systems e-mail Reflector called FlexEdge. It is used for posting topics related to SDR software innovation and other technical SDR topics. _______________________________________________ Flexedge mailing list [email protected] http://mail.flex-radio.biz/mailman/listinfo/flexedge_flex-radio.biz This is the FlexRadio Systems e-mail Reflector called FlexEdge. It is used for posting topics related to SDR software innovation and other technical SDR topics.
