Request for Comments - RadioReference Web Service

[blantonl]

Attention Scanner Application Developers... Request for Comments on the new RadioReference.com Web service specification.

The Web service is up and running now in beta. Note that you must be a donating user to have access to the Web service. If you are an application developer and need access, please let me know via PM.

Please post your comments to this thread.

Please read further down the thread for the latest version of the spec
Thanks!

 

[adamleff]

Lindsay-

This is fantastic. Schema's great, easy to parse, nice and fast, will be very helpful to me and others, I'm sure.

Well done,
~Adam

 

[UPMan]

Great job, Lindsay!

Initial comment:

UPM 1) How about adding three more optional attributes to the "site" element as:

latitude Latitude of the site
longitude Longitude of the site
radius Approximate coverage radius (in miles) of the site.

Would allow for some automated site and/or system selection based on user's current location.

 

[blantonl]

Lindsay-

This is fantastic. Schema's great, easy to parse, nice and fast, will be very helpful to me and others, I'm sure.

Well done,
~Adam

Adam, would you mind sharing with us how this will be helpful for you? What uses/applications are you planning on using this for?

-Lb

 

[blantonl]

UPM 1) How about adding three more optional attributes to the "site" element as:

latitude Latitude of the site
longitude Longitude of the site
radius Approximate coverage radius (in miles) of the site.

A couple issues here.

First being that we don't have any of this data currently, and second, a "site" defined to a trunked system is logical -- meaning, a number of different transmitters can comprise of a site (i.e. a simulcast site with multiple locations).

Let me give this some thought.

I've also realized that I need to add Radio IDs as well into the standard.

 

[ryanpape]

What about a real web service?

I would use caution in using the term "Web Service". While it is undoubtly a "service" that runs over the "web", web services are a specific thing, of which this is not one of.

For that matter, exposing this information through a "real" web service would potentially allow all sorts of intergration in software that has built in support for web services (or will...)

 

[blantonl]

Re: What about a real web service?

I would use caution in using the term "Web Service". While it is undoubtly a "service" that runs over the "web", web services are a specific thing, of which this is not one of.

Ryan, allow me to retort... 8)

From http://www.webopedia.com

The term Web services describes a standardized way of integrating Web-based applications using the XML, SOAP, WSDL and UDDI open standards over an Internet protocol backbone. XML is used to tag the data, SOAP is used to transfer the data, WSDL is used for describing the services available and UDDI is used for listing what services are available. Used primarily as a means for businesses to communicate with each other and with clients, Web services allow organizations to communicate data without intimate knowledge of each other's IT systems behind the firewall.

Web services allow different applications from different sources to communicate with each other without time-consuming custom coding, and because all communication is in XML, Web services are not tied to any one operating system or programming language. For example, Java can talk with Perl, Windows applications can talk with UNIX applications.


While we are not using SOAP (yet) - there are a number of applications currently under development that will exploit this Web service that we have made available. :wink:

I believe that we meet most of the constraints in the above definition.

 

[ryanpape]

I disagree that XML (and a web server) meet the criteria even by that defintion. (I would count SOAP and WSDL as two important ones)

However, the distinction is (almost) entirely semantic and nevertheless I think this is a great thing, regardless of the implementation details.

 

[Guest]

Thanks for adding this feature! I've been waiting for something like this for a long time.

I thought I was almost done with my BC246T software... guess I need to add a import from RadioReference.com feature. The service specs look well defined, easy to parse and implement.

Peter

 

[pgogas]

Sorry... last post was from me. Forgot to login first.

Peter

 

[UPMan]

Additional Comment:

UPM 2) As an attribute of the trs element, it would make life easier for the person exporting the system into something to be used by a scanner if there was a band attribute for Motorola I/II/IIi flavored (1,2,3,4,5,23,24)systems (I don't think other system types care):

800 Standard
800 Splinter
800 12.5 <--- proposed as part of NEXTEL solution
900
VHF
UHF

All except 800 Standard, 800 Splinter, and 800 12.5 could be easily derived by character parsing a frequency, but at least those variations either need their own attribute or you will need to make 21 additional flavors to cover these possibilities.

 

[elnerdo]

This is fantastic.

I've been just opening PDFs on my PocketPC phone and having a hellish time scrolling, zooming, etc to get freq data while I'm on the go.

The ability for me to make a small Windows Mobile app that can call to the RRDB itself over my GPRS web connection means I don't have to worry about carrying a notebook around anymore.

I'm going to try and prototype something in VS.NET over the next little while... I'd be happy to share it with anyone else out there that's using a Windows Mobile Phone, or a Windows Mobile PDA with Wi-Fi.

 

[eorange]

I'm going to try and prototype something in VS.NET over the next little while... I'd be happy to share it with anyone else out there that's using a Windows Mobile Phone, or a Windows Mobile PDA with Wi-Fi.

I'll take you up on that! I have an iPaq with PPC2003 and Wi-Fi and will gladly test/play/experiment/whatever.

Erik

 

[elnerdo]

I'll take you up on that! I have an iPaq with PPC2003 and Wi-Fi and will gladly test/play/experiment/whatever.

Erik

Cool. I'm going to prototype a couple of sample screens tonight and I'll probably start coding over the next couple of days.

I'll keep you in the loop.

(also, *if* I can get this to work, I'll be releasing it free to whomever wants it... maybe if it's good, Lindsay can stick it on the site for everyone to have.)

 

[elnerdo]

Cool. I'm going to prototype a couple of sample screens tonight and I'll probably start coding over the next couple of days.

I'll keep you in the loop.

Well, I played with VB.NET last night... and I ran into a couple of bumps.
So it may take me a little longer than I thought... but I'll report back in a couple of weeks.

-R

 

[blantonl]

(also, *if* I can get this to work, I'll be releasing it free to whomever wants it... maybe if it's good, Lindsay can stick it on the site for everyone to have.)

Absolutely... you got it!

 

[blantonl]

Additional Comment:

UPM 2) As an attribute of the trs element, it would make life easier for the person exporting the system into something to be used by a scanner if there was a band attribute for Motorola I/II/IIi flavored (1,2,3,4,5,23,24)systems (I don't think other system types care):

800 Standard
800 Splinter
800 12.5 <--- proposed as part of NEXTEL solution
900
VHF
UHF

All except 800 Standard, 800 Splinter, and 800 12.5 could be easily derived by character parsing a frequency, but at least those variations either need their own attribute or you will need to make 21 additional flavors to cover these possibilities.

I understand this requirement... let me give this one some thought as to how I would implement it in the database -- We've never tracked this before in the database.

Most of this is solved with the bandplan elements.. (UHF/VHF) - however it's the 800 MHz splinter sys stuff that I see this being an issue for.

Thinking.........

 

[BenScan]

Lindsay,

Looks great at first glance. Kind of gives me the itch to program some more.

I'd like to see a way of filtering on police, fire, EMS, public works, etc., or more accurately, have the ability to filter in my software.
Thanks,
Ben

 

[eorange]

Lindsay,

As the webmaster - any security thoughts on the password being part of the URL? Whether a client makes these requests with a browser or an application, the URL - and therefore the username/password combo - will be visibly logged in many places, like proxy servers, your server access logs, etc.

The implication is this could lead to compromised accounts.

Thanks.
Erik

 

[elnerdo]

Lindsay,

As the webmaster - any security thoughts on the password being part of the URL? Whether a client makes these requests with a browser or an application, the URL - and therefore the username/password combo - will be visibly logged in many places, like proxy servers, your server access logs, etc.

The implication is this could lead to compromised accounts.

Thanks.
Erik

I was curious about the sending of account info in plaintext as well; I just assumed that it was a temporary thing and would be addressed later on.

I also figured that when I was ready to do some serious app testing, which I assumed would be before this issue was addressed, I would just create a dummy account and have it make a small donation.