[Xastir] Feature idea for Xastir

[Gerry Creager]

Brad Douglas wrote:
> On Thu, 2007-10-04 at 14:27 -0400, William McKeehan wrote:
>> Well, the last time we discussed this, I think this is where the discussion
>> ended (after we managed to get a piglatin translation added to the
>> repository).
>>
>> I've been playing and thinking about this a fair amount. What about using
>> HTML/JavaScript/XML ala Ajax? This would require Xastir having an "http" style
>> server that would serve up pages and would respond to certain queries with XML
>> code. For example if Xastir's server were listening on port 8001,
>> http://localhost:8001/getStationInformation?callsignssid=KI4HDU-2 would
>> respond with something like
>> <station>
>>     <CallsignSSID>KI4HDU-2</CallsignSSID>
>>     <PacketsReceived>75</PacketsReceived>
>>     <LastHeard>10/04/2007 14:05:08</LastHeard>
>>     <Comments>
>>         <Comment>10/04 14:05 : .open2300v1.10</Comment>
>>         <Comment>10/04 14:00 :</Comment>
>>     </Comments>
>> .
>> .
>> .
>> </station>
> 
> Are you suggesting that everyone have a working http server on their
> local machine?  That is quite an excessive (and generally insecure)
> method of accomplishing the given goal, locally.

I don't seem to have too much in the way of security problems with web 
servers on darned near everything we stand up, either apache or tomcat. 
  We also run some stand-alone systems.  I do tend to look for 
excessive, unsuccessful login attempts and automatically block them, and 
my iptables rules are pretty tight, but standing up a basic web server 
and securing it isn't a big deal.  Or, am I demonstrating, again, how 
warped I've become?

>> Other things like
>> http://localhost:8001/findStation?callsignssid=KI4HDU-2&exact=1 would cause
>> the UI to behave as if someone had used the "Station-> Find Station" dialog
>> box.
>>
>> To facilitate this, we could provide an Xastir "Object" in JavaScript that
>> would handle most of the heavy lifting here's a rough (very) start...
>>
>> function XastirObject() {
>>     this.myConn=null;
>>     this.getStationInformation=getStationInformation;
>>     this.findStation=findStation;
>>
>>     this.myConn = new XHConn();
>>     if (!this.myConn) alert("XMLHTTP not available.");
>>     if (!this.myConn) return;
>> }
>>
>> function findStation(CallsignSSID) {
>>     this.getStation(CallsignSSID, xastirFindStation);
>> }
>>
>> function xastirFindStation(oXML) {
>>     var xml = oXML.responseXML;
>>     alert( oXML.responseText );
>>     var station = xml.getElementsByTagName( 'station' )[0].firstChild;
>>
>>     var newStation = new station();
>>     newStation.CallsignSSID = station.getElementsByTagName('name')[0].firstChild;
>>     newStation.find();
>> }
>>
>> function getStationInformation(CallsignSSID, fnToDo) {
>>    this.myConn.connect("http://localhost:8001/getStationInformation", "POST",
>> "CallsignSSID=" + CallsignSSID, fnToDo);
>> }
>>
>> function station() {
>>     this.CallsignSSID = "";
>>     this.find=find;
>>     this.send=send;
>>     return this;
>> }
>>
>> function find() {
>>     Alert("Ask Xastir to 'find' " + this.CallsignSSID + ".");
>> }
>>
>>
>> Does this sound like something that would be useful? Personally, I think this
>> would let people develop their own APRS "interface" using Xastir to do the
>> heavy lifting - and I think that if done correctly, this would eventually let
>> you run Xastir in a daemon mode and only use this interface if you wanted to.
> 
> IMO, wxPython is the way to go for GUI development.

IMNSHO, either will do.  I write more javascript these days than python, 
as someone else has become the python guru around here.

>> I imagine that adding a simple http server to the code would be pretty
>> straight forward; the only question would be if that server would be able to
>> get the data to answer the queries with easily.

I suspect that, if you're talking SOAP services (and WSDL) you're gonna 
end up with a tomcat server.  Still easy to secure, not, in my 
experience, quite as easy to configure as apache.

>> Thoughts?
> 
> I highly recommend you look into REST[1] before proceeding.
> 
> [1]
> http://www.workflowresearch.com/Publications/PDF/MIZU.JENI.KESW-DSS(2004).pdf

I strongly prefer RESTful services, too.

gerry

-- 
Gerry Creager -- gerry.creager at tamu.edu
Texas Mesonet -- AATLT, Texas A&M University
Cell: 979.229.5301 Office: 979.862.3982 FAX: 979.862.3983
Office: 1700 Research Parkway Ste 160, TAMU, College Station, TX 77843