<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'>The one problem I see with this whole scheme is that it requires a linear iteration over all possible patterns, because there is no encoded way to hierarchically organize the patterns to minimize the number of matches per tocall, and it could get a mismatch on a coarse pattern. Even if you find a match on a coarse pattern, you still have to try all the fine patterns under that coarse one to see if it is something else (ex.: APInnn for Icom versus APICxx for HA9MCQ PIC Igate versus APICQn for ICQ). So, it gets computationally worse as new subsets are defined.<br><br>I have a scheme (implemented in YAAC) that depended on the left-to-right assignment of more fixed characters for sub-divisions of a block, allowing me to do a sort of Btree search for efficiency. But, of course, that was broken by the APnnnD and APnnnU definitions.<br><br>Would it be possible to hierarchically link the patterns so if (for example), you matched on APIxxx, it would then try APICxx, and then APICQ, until a match failure occurred or the end of the finer patterns was reached?<br><br>I'm just trying to find a way to lower the burden on clients. Both the clients running on cheap computers with software TNCs (which therefore have extremely busy CPUs) and the giant clients taking full APRS-IS feeds could be impacted by an ever-growing list of tocall patterns that would ever-increase the computational burden on a per-packet basis (unless the client didn't need the lookup on a per-packet basis).<br><br>Andrew Pavlin, KA2DDO<br><br><div>Date: Thu, 24 Oct 2013 11:28:58 +0200<br>From: georg@op-co.de<br>To: aprssig@tapr.org<br>Subject: Re: [aprssig] APRS device identifiers (tocalls) in YAML, XML and JSON<br><br><pre>* Heikki Hannikainen <hessu@hes.iki.fi> [2013-10-24 08:43]:<br>> I would prefer taking a regexp library (pcre) and just throw the<br>> tocall spec found in the database file at it, instead of writing my<br>> own converters, since writing custom converters takes time and effort<br>> and may introduce bugs. String matching is sooooo a solved problem<br>> already. :)<br> <br>+1 on that. I would really like to have an easy way (regular<br>expressions) to a) determine the client info block and b) extract the<br>version number.<br> <br>My proposal would be to leave the tocall as-is, and add another<br>(slightly redundant) "regex" field that allows to match for the tocall<br>and to extract the version number, e.g. "^APWM(\d\d)$" (I hope I did not<br>botch the syntax now, but the point is just to make the intent clear).<br> <br>Does YAML require any type of escaping for such strings?<br> <br>73 de Georg DO1GL<br>-- <br>APRSdroid - Open Source APRS Client for Android | <a href="http://aprsdroid.org/m" target="_blank">http://aprsdroid.org/m</a><br><a href="https://play.google.com/store/apps/details?id=org.aprsdroid.app" target="_blank">https://play.google.com/store/apps/details?id=org.aprsdroid.app</a> | @APRSdroid<br></pre><br>_______________________________________________
aprssig mailing list
aprssig@tapr.org
http://www.tapr.org/mailman/listinfo/aprssig</div> </div></body>
</html>