[aprssig] [aprsisce] Adding additional symbols
Lynn W. Deffenbaugh (Mr)
ldeffenb at homeside.to
Wed Oct 2 05:24:27 CDT 2013
This conversation has gone well beyond the immediate scope of
APRSISCE/32. Further responses to the topic should be on the aprssig
On 10/2/2013 12:02 AM, Heikki Hannikainen wrote:
> Whatever comes out of this should be produced in the form of a
> MACHINE READABLE CONFIGURATION FILE
+1 to that suggestion, however...
> (JSON, XML, CSV, or YAML file) that could be loaded into different
> client applications, without any need for the client software author
> to manually track magic human-readable .html / .txt files in various
> URLs. That sort of work is a completely unnecessarily duplicated
> effort for us all.
Agreed, but unfortunately the reason for there being so many different
machine readable formats is that each is easier for some particular
producer/consumer platform. My personal preference is XML. (What
follows is definitely only my personal opinions)
JSON - is not very humanly readable and a beast to manually produce
XML - humanly readable, humanly editable, verify-ably "correct" (tags
closed), extensible (elements can be ignored), suffers from verbosity
CSV - easy to produce, not easy to verify correctness
YAML - just read about it, seems hard to humanly edit? Not sure about
TXT - humanly readable, machine readable if fixed format, but not
> Such a configuration file defining symbols could possibly even be
> UPDATED AUTOMATICALLY
> to different client applications around the world, by those clients
> downloading it from somewhere, without any need for the application
> author to actually build and redistribute a new version of the client.
Well, I'm not likely to code logic into APRSISCE/32 to automatically
fetch fundamental definitions from a non-controlled server and
automatically incorporate them into the application's execution. Not to
mention the magnified hits that such a server would take when 25,000
individual clients start checking for updates on an hourly basis (or
faster if some client author goofs). I'll still probably download,
verify, and then release changes with a provision for...
> Something like this happens already: People can actually download
> Steven's icon set files and install them in UI-View and a number of
> other apps (that's what I put in aprs.fi <http://aprs.fi> actually).
> It's the closest thing to a standard we have now! Too bad it only
> includes graphics, and not the text definitions.
Yes, *people* do (manually), but *applications *don't (automatically
that I'm aware of). There's a vast difference in scale and
issue-resolution when a) applications periodically troll for updates,
and then b) automatically download the detected update only to discover
that the central repository maintainer goofed and put up a 16 bit
unicode-formatted file instead of 8 bit ASCII for some textual
representation or had an incomplete upload of an image file resulting in
planet-wide corruption of people's displayed symbols.
No thank you. I'll continue to poll for changes, verify their
integrity, and then make them available to my client users.
And when a person requests an update and things go worng (sic), they
know what happened and (hopefully) know how to revert the changes. When
an application automatically downloads changes in the wee hours of the
morning and things are all awry the next time the user notices, well,
most of us have enough experience with the old Windows Updates to know
where I'm going here. (Although it has been a while since I've seen
Windows Updates mess up machines, but then again, which USB to serial
drivers recently updated causing a bunch of knock-off-clone hardware to
quit working? See my point?)
> I currently manually maintain the Ham::APRS::DeviceID module, which
> contains a machine-readable definition of APRS device identifiers
> (tocalls, mic-e identifiers). Take a look at
> http://cpansearch.perl.org/src/HESSU/Ham-APRS-DeviceID-1.06/DeviceID.pm and
> scroll back a bit to see the @dstcall_regexps hash definition. I have
> to manually track changes in http://www.aprs.org/aprs11/tocalls.txt
> and update them in my code. If tocalls.txt was published in a
> machine-readable config file format, that could simply be read in and
> used by all the client apps, without the need for everyone to manually
> track quiet changes in tocalls.txt.
Yep, I finally got tired of pinging Bob about "stealth updates" and put
his URLs on a web page watcher. At least I get a reliable (if I trust
the web service) notification of changes, although now that I think
about it, it would be nicer yet if his text files would be in a Wiki
that we could do version difference views of.
I did look at your DeviceID.pm and it looks really handy for Perl
applications (or those that might be able to invoke Perl modules), and
the information inside would be useful in applications that use regular
expressions, but that's certainly not guaranteed. Personally, I just
take Bob's APWAxx or APXnnn and use them (nearly) directly. xx are any
alpha-numeric characters while nnn are any numeric character. I do
have to order the list so that APWAxx trumps APWxxx and so forth.
But in the realm of verify-ability, my approach stinks as it relies on
the author (Bob, in this case) to pay close attention to what is typed.
IIRC there are some assignments showing nnn where the software is
actually using xxx in their ToCall. And then there's the wonderfulness
of APRXxx for <39 and >40. So, what's with APRSX40?
> Maybe I should extract that stuff from DeviceID's perl code and
> publish it in YAML format instead. That'd make it more usable for
> APRSIS32 and other apps in other languages. Lynn, would you be
> interested in using that for device identification?
As I mentioned above, I don't use regular expressions. The closer the
humanly maintained/machine readable representation is to the source, the
better as far as I'm concerned. Any additions like regex or maps or
hashes is placing assumptions on the information consumer platform. But
we've digressed from symbols to application identifiers here. But in
both cases, I'd encourage KISS. (BTW, I also have other techniques for
identifying platforms that go beyond Mic-E and >APxxxx).
In conclusion, I'm all for machine readability, especially of symbol
definitions, but even there I'm facing yet another hurdle. I'm making a
foray into a new development platform and have a need for higher
resolution symbols than the 19x19 (IIRC) content of the current symbol
set. And I'm further working on a classification of symbols to make it
easier to navigate a configuration dialog to select a symbol for use.
And of course, a symbol might be in multiple classifications.
So, do we KISS it and centralize that symbol(xy) has a (n English?)
description and a graphical representation? Do we include multiple
language descriptions (or let the application's translation layer key on
the English words or hash the English description forever playing
catchup/correction for tweaks and new ones)? Do the graphical
representations continue in the current resolution (and are they GIF or
BMP or PNG)? Or do we redefine them all into a vector format like SVG
(which I'm sure Bob would love)? Or do we offer them standardly in a
super-high-resolution and let software authors scale them down (and
clean them up for visibilty)?
And is the design going to be done by a global community with 1,000s of
axes to grind and ideas to be fielded (ever coded Ada or SGML?) or
should we take it to a core group of actual software authors to hash out
what is "reasonable" and "sufficient"?
Remember, the original goal was to (finally) add a few more "standard"
symbols to the currently defined set. And maybe (hopefully) get a
(skilled) volunteer to actually provide some renderings of the extended
symbols already defined in http://www.aprs.org/symbols/symbols-new.txt.
How much further we take it is entirely up to those willing to do the work.
Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the aprssig