[aprssig] distributed findu possible ?

[Steve Dimse]

On Aug 10, 2008, at 1:27 PM, Heikki Hannikainen wrote:

>
>  Hi guys, especially Steve,
>
> On Sun, 10 Aug 2008, Steve Dimse wrote:
>> Matti Aarnio wrote:
>>> It is much much easier to point aprs.fi's map for the general area  
>>> of interest, and then look at what happens around there.
>>
>> Of course it is. I wish I had time to program a full gmap
>> implementation on findU. My point though is you cannot call something
>> a distributed findU if it only has the easy features of findU. The
>> database aspect of the aprs.fi front page is trivial. In fact, I was
>> doing it in memory, without a database backend 12 years ago as part  
>> of
>> APRServ, the original APRS hub program.
>
>  Hm, I always thought the automatically-updating-without-reloading  
> real-time map view was really the hardest part to get working  
> properly and in a speedy manner. It does run from memory, of course,  
> since it produces an awful lot of update requests per second.

In case you don't know, I choose my words carefully. Did you noticed I  
said the "database aspect of the aprs.fi front page", right? That was  
what I said, because that was what I meant. Nothing about  
"automatically-updating-without-reloading real-time map view". Just  
the database part of it. It is not hard to write a program that sorts  
roughly 16,000 objects in memory and returns the position of any given  
a name, or returns a list of positions of nearby objects when given a  
location. In perl, maybe 10 lines.

I had that sort of thing running (albeit with maybe 2-3,000 positions,  
because that was all that was on the APRS IS) running as part of  
APRServ 11 years ago, and that was on a 16 MHz 68030 Macintosh. I'm  
sorry, but it just isn't hard.

The rest of it? I don't know, but I suspect it wouldn't be the hardest  
code I've written, I know Byon got GoogleAPRS up pretty quickly. I  
could be wrong. I don't know, and I never said anything to imply I did  
know. I'd love to find out just how hard it is, but I have no time to  
work on new features.
>
>
>  Parsing APRS packets would also have been difficult, but luckily  
> OH2KKU had written a good parser for almost all of the formats  
> already:

I've written three parsers, in Java, C, and Perl. It really isn't that  
difficult. Painful dealing with the spec, but programmatically pretty  
easy.
>
>
>  http://search.cpan.org/~hessu/Ham-APRS-FAP-1.12/
>
>> I'm not saying aprs.fi is not useful, or wrong, or anything of any
>> sort negative. I'm simply saying that you cannot talk about something
>> as a findU analog if it only cherry-picks the easy stuff.
>
>  Thanks. I have to admit that some cherry-picking has been necessary -

Again, I think you took this much too personally. I wrote "I'm simply  
saying that you cannot talk about something as a findU analog if it  
only cherry-picks the easy stuff." I said it that way because I meant  
it that way. I made findU.com. Even though I didn't pay the money to  
trademark findU (the way Bob did with APRS), I still feel I have a  
right to define what the term findU stands for. In other words, this  
statement is about what can and can't be called a findU analog. Give  
it any other name and it is fine. Just not "distributed findU"!

> findu.com has so many different kinds of views and modes that it  
> would take a lot of time to implement all of them at once. It  
> probably took you quite a while. And simply doing it all again  
> without doing some things differently (and hopefully, in someones  
> view, in a slightly better way), would be entirely pointless.

It would have a big point to me. I want someone to write the findU  
killer so I can get my life back! Of course you would do a lot of  
things differently. There are plenty of mistakes in findU to be  
learned from! When I first saw your system I had high hopes, but my  
traffic has not decreased. Unless you do the other stuff I don't think  
I'll see my traffic drop.

> It would be no fun to do a plain plagiate copy without adding some  
> of your own flavour. So, I'm doing the things which seem fun and  
> interesting to me at first, and then slowly doing the smaller things  
> later, when time allows. Call that cherry-picking if you like,  
> that's OK. But "easyness" has not been the motivator.

The cherry picking comment was not aimed at you. It was aimed at the  
people that were talking about writing a "distributed findU" that did  
nothing but show present positions and nearby objects. I was  
protecting the name of my creation, the champions of this new plan  
have picked up on that and changed the name of the thread to something  
generic, which makes me happy. You never claimed to be a findU  
anything, and none of that comment was aimed at you in any way.
>
>  I've been wondering - Steve, what would you consider the "hard  
> stuff"? Adding a specific time range parameter for weather/telemetry  
> history graphs would be very simple, in my opinion (maybe 10 lines  
> of code to catch the URL argument, validating and putting it in the  
> SQL query),

The hard stuff, as I've said, is keeping two servers with 200+GB  
databases serving millions of dynamic web pages a day operating  
reliably. Companies hire full time IT staffs to handle lower loads.

>  Anyway - thank you, Steve! Looking at findu.com has given me a lot  
> of ideas, and *the* original idea to actually start working on  
> aprs.fi in the first place. I like writing software on my spare  
> time, and doing aprs.fi has been a lot of fun during the past 1½  
> years. I do not intend to implement everything that findu does to  
> make a full replacement.

I can't tell you how bummed I am to hear that. Guess I should face the  
fact that no one is that stupid ;-)

Steve K4HG