Subj : A TCP/IP variation of -N
To : David Noon
From : Mike Luther
Date : Sun Aug 26 2001 02:09 am
Yes, Dave ..
DN> As I wrote in my follow-up to your identical request
DN> on Usenet, the way to
DN> go about this is to perform the raw extraction on the server. If you view
DN> this request as a database table and you wish to extract selected row(s)
DN> from said table, the way to go about that is to have the server run some
DN> code that extracts the row(s) you want and download them.
DN> This means that ftp itself does not need any real modification -- just
DN> smarter servers. I offered the U.K. mirror of Hobbes
DN> as an example, but it
DN> uses Web pages to offer the zip file's contents for selection. While http
DN> is somewhat slower than ftp, the difference over a
DN> cable modem is sod all.
You are totally correct, Dave, And the reason I didn't go forward with what
was offered there, is that it seems it's more civilized to kick things around
here in Fido, so I'll try to do that.
The problem, as I see it is in that last sentence you offered:
DN> While http is somewhat slower than ftp, the difference
DN> over a cable modem is sod all.
Under the conventional way of handling FTP for information and data recovery,
we can recover a PAGE or PAGES of data. When we see it displayed on the
download end, it is what is in the PAGE that is what we see, Since the content
in the page is accurate, the underpinning file that is a part of it is
transparent to the user, but is *NOT* the same. It does not have the same date
and time stamp as the source.
HTTP has no underling method, which I know about, to match the file date and
time stamp between the systems, It does match the contents of the file. If you
think about the question I posed, you'll realize that what I was shooting at
was replication of FILES, based on and including their exact time and date
stamp. The core of the question spoke toward knowing whether or not to get or
not get any particular file, or record, as a result of its file stamp time. We
absolutely have to maintain file stamp date and time,and, yes, in some case,
even the EA's, just to precisely match the information package between the
boxes!
If you look at a couple of threadlettes on this that have been in the Usegroups
too, you'll see that there simply isn't any provision that has ever been set
forth for HTTP that will provide this. If you use HTTP to create a maintenace
database of files, names, dates and times, for example,to chart the on-going
fix-everything for any OS/2 box, or complicated system; you'll fail. That's
because there is no way to display the entire collection so that you are *SURE*
that the file you have is the right one.
A prime example of that is what has happened to the various files that make or
break the Adaptec SCSI driver operation for OS/2.
There are super-critical applications now coming to focus which have legal
requirements concerning this in medicine for example. In short, the FDA here
in the USA is very specific. What was stored, in total, has to be what is
transmitted, stored, and recovered, in exactly the same fashion as it was
archived. 100% lossless is the rule. That's everything, including file dates
and times, just so that there is absolutely no question that what was archived,
is exactly the precise same thing that the next person gets, sees,and uses in
making their decision on what to do in any given case.
Yes, the other side of this is there too. Once you get it, and you, as
qualified party, decide to do something with the data, at the requesting site,
it may change form, get bound up in some other file or data form. That's just
fine. The issue is that under no circumstances can the sommunications forum,
in a quaint sort of way, be allowed to alter the data in any way between two
different institutional parties.
The confusion, I think, as to the applicability of all this arrises on not
realizing what the rules really are for the transmission between parties!
I'll attempt to explain.
A given institution, internal to itself, may do what it wants to in respect to
how it faces eventual liability for errors. Different institutions will have,
in every respect, complete information identity 100 lossless between them. It's
been so ordained; case closed.
I request a specific couple of chunks of data from a different institution that
is using even my code, yet operated by different folks. What is requested is
going to be just one file of, say hundreds of thousands that are part of an
'Empire Central' archive. It's the file stamp which is the key toward
applicatbility!
It may, indeed be shown as necessary in that it has a later date than the one
locally. That's how we know it is needed. And that extends down even into the
code locally everywhere too! But that's my choice as the design feller. Not
everyone thinks like that at all!
Forget, for the moment, check-sum authenticity and all that. At the moment,we
can't even handle any of that, in practice, with HTTP, as I see it. And,as
others have illustrated, in answer to my question, .ZIP's have the index of all
the freight cars in the train are in the Brakeman's hip pocket in the crummy!
Which is why the railroads all got rid of the Cabooses and park the Brakeman in
the second diesel where the ride is mighty lonely, mighty lonely, if you know a
bit about whatever happened to Jimmy Rogers and so on,dey's a whole lot more
lonely brakemen now riding the rails then there ever used to be!
You know, Dave, if only a few requesting sites were involved, and the value of
the information could really command a price for archival and retrieval,that
would be one thing. However what I contemplate requires that hundreds of
thousands of boxes be able to make trivial requests, not often, but when needed
for tiny snippets.
In this information railroad, I think we're all going to be more like that than
many suspect in the near future, but then, that's just my opinion.
In reality, for mission-critical applications, traditional client-server, as I
see it, is really a bad setup. As I posted elsewhere, each box of hundreds of
thousands of boxes, is an embedded system, as 'tis, even without a keyboard,
incidentally! It has to stand on its own. Even if it loses contact with
Empire Central, it has to go right on working at the level of intelligence it
has in it based on last connectivity. Slowly, over time, it picks up the
patterns and nuances of what it needs to do to fight the daily battle from tiny
common snippet files that it needs for update.
But if someone walks in and empties a 45 ACP into whatever server and it can't
reach the commander, it goes right on working until it discovers, "Hey I can
talk to them again!" Status reports are exchanged, new orders are cut. We are
all happy unless something went terminal during that comm loss that there was
no way to have prevented.
That's what lawyers are for.. chuckle.
All this, of course, is what, "On demand", really means, isn't it? And yes,
Virgina, for most cases of Santa Claus, maybe a minute max is good enough, in
many cases, for yanking whatever little snip you need out of a 100 terabyte
tape in an IBM RSC-6000 AIX-400 or bigger. Grotesque? Not hardly. One IBM
storage guy here looking at all this, noted, "Well, they have more than 1700
Linux users on a single IBM Mainframe now, Mike, and it isn't even IBM! But we
are a monopoly in the mainframe world, you know."
I said, quietly, "Yes, I know."
He said, "I suppose you do want On Demand?"
I said, quietly, "Of course!"
Further affiant sayeth not. From you and others far better informed than I
will ever be, I am trying to learn, trying to learn.
Thanks for whatever time you've spent and can spend on things like this!
Mike @ 1:117/3001
--- Maximus/2 3.01
* Origin: Ziplog Public Port (1:117/3001)
