FAA KEEPS GRAPHICAL TFR PROMISE

Another case where avweb did not check "facts" as promulgated by the FAA.

When I accessed the site the avweb recommended, it was three days
old......supposed to be updated every fifteen minutes....right.

And the hot link with the message in this string shows up as nothing but
useless data.

Yea FAA.

N.

On 05 Nov 2003 02:47:10 GMT, (COUGARNFW) wrote in
Message-Id: :

Another case where avweb did not check "facts" as promulgated by the FAA.

Perhaps so.

When I accessed the site the avweb recommended, it was three days
old......supposed to be updated every fifteen minutes....right.

It now says:
WED, 5 NOV 2003 3:49 GMT.

And the hot link with the message in this string shows up as nothing but
useless data.

I'm having difficulty parsing that sentence.

I found one California TRF link that would not display the TFR data
due to a Java error, and notified the webmaster. I haven't used the
graphical TFR web site enough to form an opinion, but the resolution
of the sectional overlays isn't what you'd expect.

Recently, Larry Dighera posted:

I haven't used the graphical TFR web site enough to
form an opinion, but the resolution of the sectional
overlays isn't what you'd expect.

It is, if you recall your PP knowledge test... 8-)

Neil

When I accessed the site the avweb recommended, it was three days
old.
--
(for Email, make the obvious changes in my address)

When I accessed the site the avweb recommended, it was three days
old.


It's current for me (but no graphics yet). In some cases you need to force
your browser to fetch the newest version of the page. Your browser caches old
pages, your server caches old pages, and there are other caches everywhere down
the line. This makes (usuallky static) web sites show up faster, but plays
havoc with dynamic ones.

To force a server refresh in IE, hold the CONTROL key down while you click the
reload icon. Try similar things in Netscape (or read the directions. The
level of caching can be set as a default.

AOL is notorious for serving cached pages. It's not a bad thing, but it's
something you should be aware of.

Jose

--
(for Email, make the obvious changes in my address)

To force a server refresh in IE, hold the CONTROL key down while you click the
reload icon.

Thanks for the pointer. For touch typists, note that refresh in IE can
be done with the F5 key. Presumably Ctrl+F5 would have the same
result.

all the best -- Dan Ford
email: (put CUB in subject line)

see the Warbird's Forum at www.warbirdforum.com
and the Piper Cub Forum at www.pipercubforum.com

For touch typists, note that refresh in IE can
be done with the F5 key. Presumably Ctrl+F5 would have the same
result.


There's a difference between refresh and ctrl=refresh. Refresh gets a new
version onto your computer from the server, ctrl-refresh forces the server to
get a new version from the source.

Jose

--
(for Email, make the obvious changes in my address)

Uh... what is the "server" and what is the "source"? Also, how does it
request a refresh from the "source" differently than just from the
"server"? Is there an HTTP protocol for specifying which level of
cached information is being requested?

-Jon C.


"Teacherjh" wrote in message
...

There's a difference between refresh and ctrl=refresh. Refresh gets
a new
version onto your computer from the server, ctrl-refresh forces the
server to
get a new version from the source.

When a web page is created, it resides somewhere on a computer connected to the
internet. That's the source. When it is changed, that is the first place the
change shows up.

When you connect to the internet, your computer connects to another computer
that's already connected and will provide you internet services. That is your
server. For example, if you are on aol, then one of the aol.com computers is
your "server". (note - "your" server. Other people connected to the internet
may well have other servers)

When you request a web page, the request goes to the server. If the server has
never seen this page before, the server sends the request on down the line to
other computers connected to the internet (in a rational order) until it finds
the source, which (of course) has seen this page before. The source sends
a copy of the page up the line to your server, which then sends it to your
computer which puts it on your screen.

The next time you request that page, your computer may look in its own memory
(cache) to see if it still has the old copy. If it does (and it hasn't
"expired"), it will display the old copy rather than tie up the internet
requesting the page again and making you wait for it to be retransmitted.
Often this is what you want, but sometimes not. When you hit the "refresh"
button, your browser registers your dissatisfaction with its offering, and asks
the server for a fresh copy.

If the page is not requested often, that copy may also be stale, but the server
will give it to you anyway. Sometimes the server's copy is newer (for example,
if other people on the same server have requested the page after the server's
copy has "expired") and in that case you get the sort-of newer copy. But
sometimes that's not new enough either. So you can do a control-refresh (at
least in IE - it may be a different keystroke combination in other browsers),
which tells the server that you're not going to put up with any of this old
stuff, and to bloody well go to the source, just in case the source itself has
changed in the interim. You'll need to wait for the request to make its way
through the internet, and for all the bytes to wind their way back to your
machine.

Often this is not a big deal, but if everyone did this for static web pages, it
would provide no benefit (the page is after all the same) and would tie up too
much bandwidth. So, the user gets to choose how far to pursue this, depending
on how critical current data is.

Some pages are set up to "expire" sooner than others in cache, so that when a
request for this page comes in, it will go straight to the source. Others are
not, so that the source is left in peace (and doesn't have to pay for all the
bandwidth that would have been used sending identical copies all over the
place). This has a consequence for banner ads and web tracking too - if you
take the page from your cache or from the server, the source never knows it was
requested.

Nothing is simple with computers and the internet, and it's that way for a good
reason. I just wish companies would stop pretending it was simple, and just
explain things so that they could be understood (and used to best advantage).
After all, life isn't simple either, and people manage to live it.

Jose

====

Uh... what is the "server" and what is the "source"? Also, how does it
request a refresh from the "source" differently than just from the
"server"? Is there an HTTP protocol for specifying which level of
cached information is being requested?

-Jon C.


"Teacherjh" wrote in message
...

There's a difference between refresh and ctrl=refresh. Refresh gets
a new
version onto your computer from the server, ctrl-refresh forces the
server to
get a new version from the source.

--
(for Email, make the obvious changes in my address)

(Teacherjh) writes:

When you connect to the internet, your computer connects to another computer
that's already connected and will provide you internet services. That is your
server.

I'd call that my ISP, gateway, router, ... but not "server".

When you request a web page, the request goes to the server. If the server has
never seen this page before, the server sends the request on down the line to
other computers connected to the internet (in a rational order) until it finds
the source, which (of course) has seen this page before.

What world are we in here? You're talking about a string of
(transparent) caching proxy servers? They communicate "in a rational
order"? So this is something like a SquidCache system?

There's very little that's truly "standard" about caching HTTP proxies.
Such broad generalizations make me cringe.

'course AOL is different. But AOL is not "the Internet".

--kyler