Re: [Xastir] Feature idea for Xastir
On Tue, 2007-10-09 at 14:59 -0500, Gerry Creager wrote: > Brad Douglas wrote: > > On Tue, 2007-10-09 at 15:32 -0400, William McKeehan wrote: > >> I don't think you're hearing exactly what I'm saying. > > > > Obviously, I'm not. ;-) > > > >> I would not expect the users to "install and run a web server". If you're > >> using Xastir, you have the option now of starting a "server"; I'm talking > >> about the same thing, only having it speak a standard protocol, http. > > > > How can you execute XML-RPC without a server to interpret it? > > The process and protocols have long been established, while SOAP/WSDL do > things in a poorly reproduced manner until forced to conform. I'm an idiot. I implemented a secure httpd-less SOAP server several years ago and completely forgot about it. The only alternative for Linux at the time was libsoup. I can't begin to count how many bugs we discovered that were never resolved, so we forked it internally. If there are better (read: usable) alternatives today, I'd be in favor of a RESTful approach to client/server interaction. It would certainly give Xastir a good entry point for querying data from remote mapservers. -- 73, de Brad KB8UYR/6 ___ Xastir mailing list Xastir@xastir.org http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir
Re: [Xastir] Feature idea for Xastir
Brad Douglas wrote: On Tue, 2007-10-09 at 15:32 -0400, William McKeehan wrote: I don't think you're hearing exactly what I'm saying. Obviously, I'm not. ;-) I would not expect the users to "install and run a web server". If you're using Xastir, you have the option now of starting a "server"; I'm talking about the same thing, only having it speak a standard protocol, http. How can you execute XML-RPC without a server to interpret it? The process and protocols have long been established, while SOAP/WSDL do things in a poorly reproduced manner until forced to conform. gerry -- Gerry Creager -- [EMAIL PROTECTED] 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 ___ Xastir mailing list Xastir@xastir.org http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir
Re: Re: [Xastir] Feature idea for Xastir
Xastir would be the server and would only interpret/respond to a limited set of XML-RPC calls. -- William McKeehan KI4HDU http://mckeehan.homeip.net On Tue, October 9, 2007 3:48 pm, Brad Douglas wrote: > On Tue, 2007-10-09 at 15:32 -0400, William McKeehan wrote: >> I don't think you're hearing exactly what I'm saying. > > Obviously, I'm not. ;-) > >> I would not expect the users to "install and run a web server". If you're >> using Xastir, you have the option now of starting a "server"; I'm talking >> about the same thing, only having it speak a standard protocol, http. > > How can you execute XML-RPC without a server to interpret it? > > -- > 73, de Brad KB8UYR/6 ___ Xastir mailing list Xastir@xastir.org http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir
Re: Re: [Xastir] Feature idea for Xastir
On Tue, 2007-10-09 at 15:32 -0400, William McKeehan wrote: > I don't think you're hearing exactly what I'm saying. Obviously, I'm not. ;-) > I would not expect the users to "install and run a web server". If you're > using Xastir, you have the option now of starting a "server"; I'm talking > about the same thing, only having it speak a standard protocol, http. How can you execute XML-RPC without a server to interpret it? -- 73, de Brad KB8UYR/6 ___ Xastir mailing list Xastir@xastir.org http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir
Re: [Xastir] Feature idea for Xastir
On Tue, 2007-10-09 at 14:18 -0500, Gerry Creager wrote: > Brad Douglas wrote: > > On Thu, 2007-10-04 at 19:18 -0500, Jason Winningham wrote: > >> On Oct 4, 2007, at 7:03 PM, Tate Belden wrote: > >> > >>> Is that even possible? To standardize on a generic 'SQL' so a > >>> specific set of features offered by any one SQL server don't > >>> dictate that server and only that server can be used? > >> I seem to recall that postgres has some specific GIS-type extensions > >> (PostGIS?) that would be desirable for an xastir implementation. > > > > Yes, PostGIS has spatial extensions, but I believe requiring the user > > have a full-blown database is excessive. I use it myself, but it > > shouldn't be forced onto anyone. > > > > SQLite should suffice in parsing DBase files of reasonable size. > > And with SQLite, you lose the capability of letting the database do the > heavy lifting for geospatial queries. A PostGIS implementation is not > too hard, and a default schema is straightforward. Make larger databases optional, not a requirement. -- 73, de Brad KB8UYR/6 ___ Xastir mailing list Xastir@xastir.org http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir
Re: [Xastir] Feature idea for Xastir
Brad Douglas wrote: On Tue, 2007-10-09 at 14:03 -0500, Gerry Creager wrote: 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 KI4HDU-2 75 10/04/2007 14:05:08 10/04 14:05 : .open2300v1.10 10/04 14:00 : . . . 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? I prefer to not require that users be as security minded as we are. It's a problem waiting to happen, not to mention the fact that users will be required to install and properly setup a web server and the necessary extensions (mapserver/FDO?) in the first place. Even I have trouble getting FDO to install properly (damn you, Autodesk! ;-). I gave up on AutoDesk. I run the "normal" Mapserver code. The compile and dependencies are tricky but we could standardize on a release and config and roll out a new one periodically. Or not. [snip] 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. Again, similar to Java, JS is write once; test everywhere; rewrite; test; rewrite; test... Not all JS behaves equally in all browsers. :-( Used to think that, then I started testing for IE and just giving them an error page (Your browser doesn't support real web interaction. Please upgrade to Opera or Firefox.) and my life got better. Carefully crafted JS is usable. I suspect carefully crafted Python is, too. Given a choice I'd still write ALL my code in Fortran... Python is surprisingly easy to learn and does not suffer to licensing and flame wars others are subjected to. I've made my case so I'll shut up, now. YMMV. I work in Fortran for most of my coding these days. Yes, Fortran. That's what weather models are generally written in. I wrote my geodetic processing code, and modified someone else's, in Fortran, too. I suspect that, when I really have to, I'll go learn Python. I know there's not a good graphics development object in f90 or f95 I can use. :-( gerry -- Gerry Creager -- [EMAIL PROTECTED] 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 ___ Xastir mailing list Xastir@xastir.org http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir
Re: Re: [Xastir] Feature idea for Xastir
I don't think you're hearing exactly what I'm saying. I would not expect the users to "install and run a web server". If you're using Xastir, you have the option now of starting a "server"; I'm talking about the same thing, only having it speak a standard protocol, http. -- William McKeehan KI4HDU http://mckeehan.homeip.net On Tue, October 9, 2007 3:16 pm, Brad Douglas wrote: > On Tue, 2007-10-09 at 15:02 -0400, William McKeehan wrote: >> On Tue, October 9, 2007 2:46 pm, Brad Douglas wrote: >> > 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. >> >> Well, I'm thinking about a limited http server as part of Xastir, not >> necessarily on port 80 (the default http port). It would be similar to the >> current Xastir server port. I think we could find code for a simple http >> engine to incorporate into the Xastir code that is neither excessive nor >> insecure. > > If that happens, I will stop using Xastir. It is unreasonable to > require users to install and run a web server for a single application. > Web GUIs are highly limited in functionality. > >> > IMO, wxPython is the way to go for GUI development. >> >> My suggested approach would let people develop a GUI in multiple >> environments >> and provide a standard "API" to facilitate this development. > > This is not practical, IMO. > > > -- > 73, de Brad KB8UYR/6 > > > ___ Xastir mailing list Xastir@xastir.org http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir
Re: [Xastir] Feature idea for Xastir
Within this past year. I have friends that work at deCarta. On Tue, 2007-10-09 at 14:19 -0500, Gerry Creager wrote: > Interesting. Happened within the last 2 weeks? > > > Brad Douglas wrote: > > On Fri, 2007-10-05 at 22:53 -0500, Gerry Creager wrote: > >> Google and Mapquest get their basemaps, if memory serves, from Navtech. > > > > FYI, Google is now doing most things in-house. They have severed their > > ties with NavTech, deCarta and others and going direct to government. -- 73, de Brad KB8UYR/6 ___ Xastir mailing list Xastir@xastir.org http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir
Re: [Xastir] Feature idea for Xastir
I'm not talking about making the http server open to anyone; it could limit itself to 127.0.0.1 for the type of thing I'm talking about. -- William McKeehan KI4HDU http://mckeehan.homeip.net On Tue, October 9, 2007 3:16 pm, Gerry Creager wrote: > William McKeehan wrote: >> On Tue, October 9, 2007 2:46 pm, Brad Douglas wrote: >>> 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. >> >> Well, I'm thinking about a limited http server as part of Xastir, not >> necessarily on port 80 (the default http port). It would be similar to the >> current Xastir server port. I think we could find code for a simple http >> engine to incorporate into the Xastir code that is neither excessive nor >> insecure. > > Lots of (real) security professionals will ask serious questions about > standing up a web server on a port besides 80, 8080 or 8000. Be > prepared to have to answer those questions. Also, I cringe everytime I > think of the port-scamming APRS-IS is already involved in. We should > have written the spec, gone to IANA and gotten a port-list, and > implemented it. > >>> IMO, wxPython is the way to go for GUI development. >> >> My suggested approach would let people develop a GUI in multiple >> environments >> and provide a standard "API" to facilitate this development. > > That works if we're looking at exposing an interface and expecting folks > to write to it, ala SOAP. Unfortunately, then, every new SOAP service > starts looking like a "one-off" and the eventual consolidation of WSDLs > and SOAP implementations will result in... xml-rpc, which has already > been around for quite awhile. > >>> I highly recommend you look into REST[1] before proceeding. >>> >>> [1] >>> http://www.workflowresearch.com/Publications/PDF/MIZU.JENI.KESW-DSS(2004).pdf > > gerry > -- > Gerry Creager -- [EMAIL PROTECTED] > 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 > > > ___ Xastir mailing list Xastir@xastir.org http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir
Re: [Xastir] Feature idea for Xastir
On Tue, 2007-10-09 at 14:03 -0500, Gerry Creager wrote: > 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 > >> > >> KI4HDU-2 > >> 75 > >> 10/04/2007 14:05:08 > >> > >> 10/04 14:05 : .open2300v1.10 > >> 10/04 14:00 : > >> > >> . > >> . > >> . > >> > > > > 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? I prefer to not require that users be as security minded as we are. It's a problem waiting to happen, not to mention the fact that users will be required to install and properly setup a web server and the necessary extensions (mapserver/FDO?) in the first place. Even I have trouble getting FDO to install properly (damn you, Autodesk! ;-). [snip] > >> 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. Again, similar to Java, JS is write once; test everywhere; rewrite; test; rewrite; test... Not all JS behaves equally in all browsers. :-( Python is surprisingly easy to learn and does not suffer to licensing and flame wars others are subjected to. I've made my case so I'll shut up, now. YMMV. -- 73, de Brad KB8UYR/6 ___ Xastir mailing list Xastir@xastir.org http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir
Re: [Xastir] Feature idea for Xastir
Interesting. Happened within the last 2 weeks? Brad Douglas wrote: On Fri, 2007-10-05 at 22:53 -0500, Gerry Creager wrote: Google and Mapquest get their basemaps, if memory serves, from Navtech. FYI, Google is now doing most things in-house. They have severed their ties with NavTech, deCarta and others and going direct to government. -- Gerry Creager -- [EMAIL PROTECTED] 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 ___ Xastir mailing list Xastir@xastir.org http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir
Re: [Xastir] Feature idea for Xastir
Brad Douglas wrote: On Thu, 2007-10-04 at 19:18 -0500, Jason Winningham wrote: On Oct 4, 2007, at 7:03 PM, Tate Belden wrote: Is that even possible? To standardize on a generic 'SQL' so a specific set of features offered by any one SQL server don't dictate that server and only that server can be used? I seem to recall that postgres has some specific GIS-type extensions (PostGIS?) that would be desirable for an xastir implementation. Yes, PostGIS has spatial extensions, but I believe requiring the user have a full-blown database is excessive. I use it myself, but it shouldn't be forced onto anyone. SQLite should suffice in parsing DBase files of reasonable size. And with SQLite, you lose the capability of letting the database do the heavy lifting for geospatial queries. A PostGIS implementation is not too hard, and a default schema is straightforward. gerry -- Gerry Creager -- [EMAIL PROTECTED] 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 ___ Xastir mailing list Xastir@xastir.org http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir
Re: Re: [Xastir] Feature idea for Xastir
On Tue, 2007-10-09 at 15:02 -0400, William McKeehan wrote: > On Tue, October 9, 2007 2:46 pm, Brad Douglas wrote: > > 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. > > Well, I'm thinking about a limited http server as part of Xastir, not > necessarily on port 80 (the default http port). It would be similar to the > current Xastir server port. I think we could find code for a simple http > engine to incorporate into the Xastir code that is neither excessive nor > insecure. If that happens, I will stop using Xastir. It is unreasonable to require users to install and run a web server for a single application. Web GUIs are highly limited in functionality. > > IMO, wxPython is the way to go for GUI development. > > My suggested approach would let people develop a GUI in multiple environments > and provide a standard "API" to facilitate this development. This is not practical, IMO. -- 73, de Brad KB8UYR/6 ___ Xastir mailing list Xastir@xastir.org http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir
Re: [Xastir] Feature idea for Xastir
William McKeehan wrote: On Tue, October 9, 2007 2:46 pm, Brad Douglas wrote: 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. Well, I'm thinking about a limited http server as part of Xastir, not necessarily on port 80 (the default http port). It would be similar to the current Xastir server port. I think we could find code for a simple http engine to incorporate into the Xastir code that is neither excessive nor insecure. Lots of (real) security professionals will ask serious questions about standing up a web server on a port besides 80, 8080 or 8000. Be prepared to have to answer those questions. Also, I cringe everytime I think of the port-scamming APRS-IS is already involved in. We should have written the spec, gone to IANA and gotten a port-list, and implemented it. IMO, wxPython is the way to go for GUI development. My suggested approach would let people develop a GUI in multiple environments and provide a standard "API" to facilitate this development. That works if we're looking at exposing an interface and expecting folks to write to it, ala SOAP. Unfortunately, then, every new SOAP service starts looking like a "one-off" and the eventual consolidation of WSDLs and SOAP implementations will result in... xml-rpc, which has already been around for quite awhile. I highly recommend you look into REST[1] before proceeding. [1] http://www.workflowresearch.com/Publications/PDF/MIZU.JENI.KESW-DSS(2004).pdf gerry -- Gerry Creager -- [EMAIL PROTECTED] 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 ___ Xastir mailing list Xastir@xastir.org http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir
Re: [Xastir] Feature idea for Xastir
On Fri, 2007-10-05 at 22:53 -0500, Gerry Creager wrote: > Google and Mapquest get their basemaps, if memory serves, from Navtech. FYI, Google is now doing most things in-house. They have severed their ties with NavTech, deCarta and others and going direct to government. -- 73, de Brad KB8UYR/6 ___ Xastir mailing list Xastir@xastir.org http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir
Re: [Xastir] Feature idea for Xastir
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
KI4HDU-2
75
10/04/2007 14:05:08
10/04 14:05 : .open2300v1.10
10/04 14:00 :
.
.
.
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 -- [EMAIL PROTECTED]
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
___
Xastir mailing list
Xastir@xastir.org
http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir
Re: Re: [Xastir] Feature idea for Xastir
On Thu, 2007-10-04 at 19:18 -0500, Jason Winningham wrote: > On Oct 4, 2007, at 7:03 PM, Tate Belden wrote: > > > Is that even possible? To standardize on a generic 'SQL' so a > > specific set of features offered by any one SQL server don't > > dictate that server and only that server can be used? > > I seem to recall that postgres has some specific GIS-type extensions > (PostGIS?) that would be desirable for an xastir implementation. Yes, PostGIS has spatial extensions, but I believe requiring the user have a full-blown database is excessive. I use it myself, but it shouldn't be forced onto anyone. SQLite should suffice in parsing DBase files of reasonable size. -- 73, de Brad KB8UYR/6 ___ Xastir mailing list Xastir@xastir.org http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir
Re: Re: [Xastir] Feature idea for Xastir
On Tue, October 9, 2007 2:46 pm, Brad Douglas wrote: > 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. Well, I'm thinking about a limited http server as part of Xastir, not necessarily on port 80 (the default http port). It would be similar to the current Xastir server port. I think we could find code for a simple http engine to incorporate into the Xastir code that is neither excessive nor insecure. > > IMO, wxPython is the way to go for GUI development. My suggested approach would let people develop a GUI in multiple environments and provide a standard "API" to facilitate this development. > > I highly recommend you look into REST[1] before proceeding. > > [1] > http://www.workflowresearch.com/Publications/PDF/MIZU.JENI.KESW-DSS(2004).pdf > > -- > 73, de Brad KB8UYR/6 -- William McKeehan KI4HDU http://mckeehan.homeip.net ___ Xastir mailing list Xastir@xastir.org http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir
Re: X-IMail-SPAM-Connection Re: [Xastir] Feature idea for Xastir
On Thu, 2007-10-04 at 16:49 -0500, Jason Winningham wrote: > On Oct 4, 2007, at 2:50 PM, Stephen - K1LNX wrote: > > > Maps, maps and more maps. > > Ye gods, xastir already supports hundreds of formats. If there's an > area of xastir lacking, that ain't it. (: I guess I need to get back to making those tutorials. I've been getting sidetracked with other projects (GRASS development). :( > > We need the ability to use Google maps > > Licensing issues could problematic, but I think someone is already > keeping an eye on that. Google does not have a compatible license, although they aren't exactly enforcing it, either. I avoid Google imagery at all costs for a variety of reasons. Licensing just happens to be near the top of the list. > I suspect something more like our own internet map server (or set of > servers) could be useful, so that the free map data that's available > could be stored in such a way it could be displayed nicely and > consistently. An added bonus to this method would be that those of > us who operate mobile/internet-less could duplicate the mapserver > with our personal dataset. I've considered doing this. I have capable web hosting, but have lacked the time to put mapserver up. This would also most likely include a fork() of OSM that enforces data integrity. > > True cross-platform compatibility. Should it be developed in Python > > or Java? Java: Write Once; Test everywhere. I'd prefer to see wxPython on the GUI. I was initially very skeptical, but I've been quite impressed with usability and interface speed. > I'd say neither, as scripting/interpreted languages (Python) don't > always scale well (there's a _lot_ of code in xastir). Python > doesn't appeal to me for another reason: minor version differences > are incompatible with each other (ImageMagick, anyone?). I've got a > reasonably complex unix enterprise configuration, and python is a > serious pain. Java seems to be a pig, performance-wise. There's no need to rewrite the core of Xastir except where relating to GUI. Tk/Tcl/*Magick is the bane of Xastir. > I'd like to see xastir remain fairly lightweight for mobile/portable > applications. > > Something like Qt (licensing issues again!) would be more desirable, > IMO. wxWidgets claims to be a similar open source cross-platform > development toolkit, but I know nothing about it (other than the only > time I tried to install on Solaris it wouldn't build without a fight). My only issue with wxPython is it's rapid development, which is not always backwards compatible. -- 73, de Brad KB8UYR/6 ___ Xastir mailing list Xastir@xastir.org http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir
Re: Re: [Xastir] Feature idea for Xastir
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
>
> KI4HDU-2
> 75
> 10/04/2007 14:05:08
>
> 10/04 14:05 : .open2300v1.10
> 10/04 14:00 :
>
> .
> .
> .
>
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.
> 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.
> 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.
>
> Thoughts?
I highly recommend you look into REST[1] before proceeding.
[1]
http://www.workflowresearch.com/Publications/PDF/MIZU.JENI.KESW-DSS(2004).pdf
--
73, de Brad KB8UYR/6
___
Xastir mailing list
Xastir@xastir.org
http://lists.xastir.org/cgi-bin/mailman/listinfo/xastir
