[aprssig] [aprsisce] Adding additional symbols

[Andrew P.]

That is an excellent idea, Hessu. I would be happy to read such a file into YAAC. My application is another that is already reading the UIView symbol files (with all the limitations you mentioned, including not supporting symbol space expansion).

One problem with configuration files of standard text is, which human language will the text be in? In YAAC, I used Java I18N (Internationalization) support to allow for restating the text messages in any language (alas, I don't speak any other languages besides English well enough to create the alternate language files). Unfortunately, Java I18N files are not necessarily portable to a program written in another computer language. So how would such standardized files be localized? I'm not trying to shut down your idea (I think it's excellent); I just want to make sure this is accounted for.

Andrew Pavlin, KA2DDO
author of YAAC ("Yet Another APRS Client")
http://www.ka2ddo.org/ka2ddo/YAAC.html

Date: Wed, 2 Oct 2013 07:02:27 +0300
From: hessu at hes.iki.fi
To: aprsisce at yahoogroups.com
CC: aprssig at tapr.org
Subject: Re: [aprssig] [aprsisce] Adding additional symbols

On Wed, Oct 2, 2013 at 1:30 AM, Robert Bruninga <bruninga at usna.edu> wrote:








        




6)  Although I came up with this expansion room just for this purpose, I am totally swamped and cannot take it on bit by bit.  If someone would like to be the symbol CZAR to collect all of  the desires, and organize them, and then make a well thought out and justified proposal, that would help.



I just found another link:  http://aprs.org/symbols.html



So that is another job,  go through all of my evolved documents on Symbols piece by piece and identify any conflicts, overlaps, errors and make any specific recommendations on how I can clean them up.



The main entry points are aprs11.html, aprs12.html, symbols.html and then all of the symbol related .TXT files they point to.  What a mess.


Whatever comes out of this should be produced in the form of a
MACHINE READABLE CONFIGURATION FILE

(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.

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.

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 actually). It's the closest thing to a standard we have now! Too bad it only includes graphics, and not the text definitions.

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.

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?

- Hessu


_______________________________________________
aprssig mailing list
aprssig at tapr.org
http://www.tapr.org/mailman/listinfo/aprssig 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20131002/57da4610/attachment.html>