<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">This conversation has gone well beyond
the immediate scope of APRSISCE/32. Further responses to the
topic should be on the aprssig mailing list.<br>
<br>
On 10/2/2013 12:02 AM, Heikki Hannikainen wrote:<br>
</div>
<blockquote
cite="mid:CAHqXQkOSm_rERAG2ihzTF+ZcJXvX5ZRW+_hKJevHEWcKM=vzqg@mail.gmail.com"
type="cite">
<div dir="ltr"><br>
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
</div>
<div style="">Whatever comes out of this should be produced
in the form of a</div>
<div style=""><br>
</div>
<div style="">MACHINE READABLE CONFIGURATION FILE</div>
</div>
</div>
</div>
</blockquote>
<br>
+1 to that suggestion, however...<br>
<br>
<blockquote
cite="mid:CAHqXQkOSm_rERAG2ihzTF+ZcJXvX5ZRW+_hKJevHEWcKM=vzqg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div style="">
<br>
</div>
<div style="">(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.</div>
</div>
</div>
</div>
</blockquote>
<br>
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)<br>
<br>
JSON - is not very humanly readable and a beast to manually produce<br>
XML - humanly readable, humanly editable, verify-ably "correct"
(tags closed), extensible (elements can be ignored), suffers from
verbosity<br>
CSV - easy to produce, not easy to verify correctness<br>
YAML - just read about it, seems hard to humanly edit? Not sure
about verify-ability?<br>
TXT - humanly readable, machine readable if fixed format, but not
verify-able<br>
<br>
<blockquote
cite="mid:CAHqXQkOSm_rERAG2ihzTF+ZcJXvX5ZRW+_hKJevHEWcKM=vzqg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div style="">Such a configuration file defining symbols
could possibly even be</div>
<div style=""><br>
</div>
<div style="">UPDATED AUTOMATICALLY</div>
<div style=""><br>
</div>
<div style="">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.</div>
</div>
</div>
</div>
</blockquote>
<br>
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...<br>
<br>
<blockquote
cite="mid:CAHqXQkOSm_rERAG2ihzTF+ZcJXvX5ZRW+_hKJevHEWcKM=vzqg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div style=""><br>
</div>
<div style="">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 <a moz-do-not-send="true" href="http://aprs.fi">aprs.fi</a>
actually). It's the closest thing to a standard we have
now! Too bad it only includes graphics, and not the text
definitions.</div>
</div>
</div>
</div>
</blockquote>
<br>
Yes, <b>people</b> do (manually), but <b>applications </b>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.<br>
<br>
No thank you. I'll continue to poll for changes, verify their
integrity, and then make them available to my client users.<br>
<br>
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?)<br>
<br>
<blockquote
cite="mid:CAHqXQkOSm_rERAG2ihzTF+ZcJXvX5ZRW+_hKJevHEWcKM=vzqg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
</div>
<div style="">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 <a
moz-do-not-send="true"
href="http://cpansearch.perl.org/src/HESSU/Ham-APRS-DeviceID-1.06/DeviceID.pm">http://cpansearch.perl.org/src/HESSU/Ham-APRS-DeviceID-1.06/DeviceID.pm</a>
and scroll back a bit to see the <span
style="color:rgb(0,0,0);white-space:pre-wrap">@dstcall_regexps</span> hash
definition. I have to manually track changes in <a
moz-do-not-send="true"
href="http://www.aprs.org/aprs11/tocalls.txt">http://www.aprs.org/aprs11/tocalls.txt</a>
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.</div>
</div>
</div>
</div>
</blockquote>
<br>
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.<br>
<br>
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.<br>
<br>
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?<br>
<br>
<blockquote
cite="mid:CAHqXQkOSm_rERAG2ihzTF+ZcJXvX5ZRW+_hKJevHEWcKM=vzqg@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div style=""><br>
</div>
<div style="">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?</div>
</div>
</div>
</div>
</blockquote>
<br>
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).<br>
<br>
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.<br>
<br>
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)?<br>
<br>
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"?<br>
<br>
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
<a class="moz-txt-link-freetext" href="http://www.aprs.org/symbols/symbols-new.txt">http://www.aprs.org/symbols/symbols-new.txt</a>. How much further we
take it is entirely up to those willing to do the work.<br>
<br>
Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32<br>
<br>
</body>
</html>