| |
ZL3AI > APRDIG 05.03.04 13:08l 219 Lines 9191 Bytes #999 (0) @ WW
BID : 2950-ZL3AI
Read: GUEST
Subj: TAPR Digest, Mar 03, 4/7
Path: DB0FHN<DB0RGB<DB0MRW<DB0ERF<DB0FBB<DB0BI<DB0NOS<DB0EA<DB0RES<ON0AR<
ON0AR<F6KMO<EA5DVS<EA5RQ<CT2GWY<W4JAX<VK4TUB<ZL2BAU<ZL2BAU<ZL3VML
Sent: 040305/1026Z @:ZL3VML.#80.NZL.OC #:20397 [Chch-NZ] FBB7.00i $:2950-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: Re: [ James Jefferson ] Re: NWS Radar trouble
From: "Gregg G. Wonderly" <gregg@skymaster.cytetech.com>
Date: Wed, 03 Mar 2004 13:36:09 -0600
X-Message-Number: 31
The merging of the maps with the icons is the problematic issue. Steve
doesn't have context or state perhaps in his generated pages. If some put
together a JSP service that would cache maps, once received, and then remerge
the icons with the maps on each subsequent request, that would eliminate the
rerequest of the map.
Or, we could use applets or real applications for this and let the map be
retrieved once, and then let the local software merge the icons with the maps.
Especially for long running sessions, the applet would be much better. Java
Web Start would be a great way to provide a web clickable way to get a large
application loaded and running outside of the browser for continuous
monitoring.
Maybe someone can take the panel inside the applet of JavAPRS and put that
into a Frame in an application and then provide a JNLP file to launch it with?
-----
gregg@cytetech.com (Cyte Technologies Inc)
----------------------------------------------------------------------
Subject: Connector for GBR-21?
From: Earl Needham <needhame@yucca.net>
Date: Wed, 03 Mar 2004 12:39:27 -0700
X-Message-Number: 32
Is there a place to get the power/data connector for a Garmin GBR-21 DGPS
receiver? I tried to get the info from Garmin, but they don't seem to be
too interested.
Thanks,
Earl
Earl Needham, KD5XB, Clovis, New Mexico DM84jk
KD5XB-2>APW251,PCSAT-1%:=3425.83N/10313.55W-PHG7150/WinAPRS 2.5.1
-EARL_CLOVIS -251-<630>
SETI@Home: 11385WU/7.39yrs
----------------------------------------------------------------------
Subject: Re: NWS Radar trouble
From: Steve Dimse <k4hg@tapr.org>
Date: Wed, 3 Mar 2004 14:43:37 -0500
X-Message-Number: 33
On 3/3/04 at 1:53 PM Jeff King <jeff@aerodata.net> sent:
>>>>From a systems standpoint if I wanted to reduce the amount of
>>>>maps requested
>>>I would do the following: 1) turn off auto refreshing and
>>>makes that a button or checkbox to enable. or
>
>>Refresh was added very early on during development at user's
>>request, my perception is my users want this.
>
>
>That is what "checkbox" means.
Thanks, I was unclear on what a checkbox is!
>The user "checks" the box if they want
>refresh. The idea, by default, is to give the user a minimal set of features,
>and only give them the richer bandwidth hog features if the user so desires.
>So your not taking anything away for the user, your just making it a pull
>operation instead of a push operation, so to speak.
One of the consistant issues I deal with is complexity. Sure, you can put
every possible option on a page, cover it with controls, and turn people
loose. Trouble is, findU is used by many people without technical
backgrounds...Aunt Tillie following Joe Ham, or my YL tracking me. I
already think the find page is too busy and would like to simplify it. The
last thing I want is to add another control.
If you haven't already read it, you ought to look at ESR's recent treatice
"The Luxury of Ignorance"
http://www.catb.org/~esr/writings/cups-horror.html
This describes Eric Raymonds recent wrestling match configuring CUPS.
Eric's basic premise is that thing ought to work the way a naive user
expects them them to work. He was writing from the standpoint of
configuration of software, but I think it applies in this case as well.
Aunt Tillie is looking at the position of something that is (potentially)
moving, so the map ought to move as well.
I'd like to think that this sort of user-focus is one of the strong points
of findU. You may disagree, but you are hardly a typical user.
>The basic premise here is good manners.... if someone is giving you something
>for free, you only use what you need, and don't fill a grocery bag at the all
>you can eat buffet. You pick only what you can eat at that particular
>sitting.
I just presented stats to show this is a minor issue, and explained it is
zero issue for the NWS as I cache those images already.
In the near future I'll be caching more maps (both APRSworld and
self-generated), I have to get more of the drawing code working before I
move on to that performance tweak, however the web site stats show there is
little issue with people just letting pages sit there open.
Until Jim took over the US maps, the only web site affected by refresh rate
was vicinity, and they obviously didn't care because the usage had been
going on for 4 years at a steadily increasing rate. From what Jim has said,
his caching means it is not a problem on his end, and before it becomes one
I hope he is able to provide instructions for others to obtain the raw data
and mapping programs to run other mapping servers, both to share the load
and to provide redundancy.
Steve K4HG
----------------------------------------------------------------------
Subject: Re: [ James Jefferson ] Re: NWS Radar trouble
From: Steve Dimse <k4hg@tapr.org>
Date: Wed, 3 Mar 2004 14:59:05 -0500
X-Message-Number: 34
On 3/3/04 at 1:36 PM Gregg G. Wonderly <gregg@skymaster.cytetech.com> sent:
>The merging of the maps with the icons is the problematic issue. Steve
>doesn't have context or state perhaps in his generated pages. If some put
>together a JSP service that would cache maps, once received, and then remerge
>the icons with the maps on each subsequent request, that would eliminate the
>rerequest of the map.
It doesn't need to be JSP. As I say, my code already caches the NWS maps,
and as Jim as said, he already caches the APRSworld maps. I do plan to
cache most maps (probably won't bother with APRSdos maps because those are
small and draw very fast, caching would be slower than drawing).
>Or, we could use applets or real applications for this and let the map be
>retrieved once, and then let the local software merge the icons with the maps.
Gee, sounds like a version of APRS that runs in Java. Didn't someone do that
(many years ago in a galaxy far, far away ;-)
There are some uses where javAPRS still provides a good solution, and I'm
glad Pete picked up development after I moved to findU. I obviously believe
findU is a better overall solution, providing much more than just positions
on map, otherwise I wouldn't have abandoned javAPRS. findU doesn't try to
be another client program showing all stations in an area...if you want
that, get Xastir or UIView or WinAPRS or anything other client program that
handles internet connections or write a javAPRS page. findU focuses on the
single station, with historical data at your fingertips, you do not need to
stay connected.
I don't believe that there is any problem being caused now by the refresh
rate...even without one of those thingamagigs (what did you call it Jeff???
oh yea, a checkbox!!!) the complete elimination of the refresh would not
significantly decrease the cache hit count. In fact, I think it would
increase it, with people hitting the refresh button more often than every
three minu= tes.
Steve K4HG
----------------------------------------------------------------------
Subject: Re: NWS Radar trouble
From: Jeff King <jeff@aerodata.net>
Date: Wed, 3 Mar 2004 15:00:35 -0500
X-Message-Number: 35
I don't disagree with anything you are saying, but the basic premises is
simple. If your getting something for free, it is a good idea to not overtax
the system or overstay your welcome. Do with that as you may. I'm simply the
kind of person that if my hosts suggests something, I pay attention and
consider what they are saying.
As far as complexity goes, I find APRSWORLD's GUI more intuitive then
FINDU's, and he has already implemented a less bandwidth greedy approach, as
suggested. So I'm not sure complexity has anything to do with it. You just
don't want to do it that way, for whatever reason, which is your decision.
----------------------------------------------------------------------
Subject: Why we wanted the data
From: Earl Needham <needhame@yucca.net>
Date: Wed, 03 Mar 2004 13:01:44 -0700
X-Message-Number: 36
At 08:06 AM 3/3/2004, Christensen, Eric wrote:
>I have posted the results of the Survey and the Destination Stats. PLEASE
>READ the associated text that goes with the graphs BEFORE commenting on
>them. I think I did okay with the disclaimers on each. Those with more
>legal skills could probably do better.
>
>http://personal.ecu.edu/christensene/Client%20Software.htm
>
>Now I forget why we were even getting the data! :)
We were discussing compressed format and which clients do or do not work
properly with compressed format. See below...
At 04:28 PM 2/24/2004, Earl Needham wrote:
>At 04:21 PM 2/24/2004, Christensen, Eric wrote:
>>What do you own that doesn't support it?
>
>For one, the HamHUD doesn't decode compressed packets properly,
>as far as I know.
>
>For another, WinAPRS doesn't decode it properly. If I'm using
>UI-View, with my symbol set to a HOUSE, and sending compressed packets,
>WinAPRS shows an island with a palm tree on it.
>
>73
>Earl
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
