[aprssig] [aprsisce] Adding additional symbols

[Lynn W. Deffenbaugh (Mr)]

This conversation has gone well beyond the immediate scope of 
APRSISCE/32.  Further responses to the topic should be on the aprssig 
mailing list.

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 
verify-ability?
TXT - humanly readable, machine readable if fixed format, but not 
verify-able

> 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...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20131002/2a56f7fa/attachment.html>