This is the first, and likely last, time
I will write a "MOD THE PARENT UP" post.
But damn, it's funny. Anything to throw
in a media reference that *isn't* borrowed
from the Simpsons.
Ummm...
think again.
Granted, they don't seem to cache the original image, but they seem to cache a smaller thumbnail, as I often am able to browse a thumbnail for an image no longer extant on the originating server.
Re:The only problem remaining:
on
Think And Click
·
· Score: 1
The only problem remaining: Getting the monkey to understand where you want to move the mouse.
While none of them were as badly written as the "C" article, none of them were well edited, and all contained basic gramatical and spelling errors. In other words, here's a magazine I won't be reading again.
In other words, here's a post I won't be reading again.
Just have the browser request the image minus the prefix; the server can then choose what type to send
That is the better route to go, but only should you be able to enable "MultiViews" (Apache) or its equivalent on the server. The downside is that I have noticed that certain User Agents (I won't name names) don't cache files delivered in this manner well at all.
[N]ote that HTTP has one feature over FTP that I forgot about until now. Content-type!
Yeah, this is a weakness in the FTP protocol - though, in it's favor, I don't think HTTP allows for LOCAL typing/interpretation. You're right, Content-Type alleviates type confusion here.
What? You've never tried to go to a page and been presented with a pop-up box asking you for user and password for such-and-such an authentication domain?
HTTP defines the "Auth-Type" header, with the two commonly supported methods "Basic" and "Digest" (the latter does not send cleartext passwords).
You originally mentioned a strength of HTTP being other means of authorization outside of plaintext. I've never seen a common working implementation of Digest Authorization.
Yes, I'm familiar with these concepts and yes, I've encountered and used Basic Authorization before.
Cookie and URL-based authorization are still plaintext transmission, by and large, and prone to their own issues. And I still think that use of SSL raises its own headaches.
Several command-line http clients implement "reget" functionality using the "Range" or "Byte-Range" (whatever it's called) HTTP header, which I think (but am not sure) even/1.0 supports.
No, Byte-Range/Range are 1.1 functionality, afaik. Things like wget are appropriate here, but are really tailored to snarfing websites, though I suppose one could tailor these implementations to a broader range of needs.
I'll leave the remainder of your post alone. You've convinced me that you can apply things as appropriate, raised a number of valid points, and similarly agree that there might not be a good, interactive HTTP client to replace FTP just yet. WebDAV developments, mentioned elsewhere, might hold promise. Who knows?
A web browser is not the type of client that can easily replace a "real" ftp client. Throwing SSL into the mix adds more maintenance overhead. No browser puts all the pieces together as far as I know, and overloading a browser to become the end-all, be-all Internet tool may be expecting too much or mere folly.
FTP requires an additional TCP connection for the control info. More setup and teardown cost. HTTP wins.
OK. I guess I'm more concerned about access (how people get files) more than anything else. HTTP/1.1 (which I see as offering the tools needed to surpass FTP) may have to make use of a second connection at times, IIRC, though.
Many sites are already running an HTTP server, so using that for file transfer means one less daemon. Mitigated by running ftpd out of inetd, which most people do, but still... HTTP wins.
I'll grant this, too. But where's the application support beyond "see the file, click on the link"? Please point me in the direction of a robust and well-supported HTTP agent that can duplicate the functionality of any standard FTP client. Please.
HTTP can use auth methods other than plaintext, and can easily have different sets of auth'd users in different directories
I'm not so certain about this. I haven't seen many auth methods implemented in clients other than https, where you incur certificate fees and more mess than "just one less daemon" implication.
What are the advantages to FTP for downloads... I honestly can't think of any ATM.
Well... implementation-specific, but:
Error recovery and restart from an arbitary point in a given file;
variable -- APPENDing, unique filename, overwrites, allocation requests, etc. -- storage (ok, this is for uploads, but...); and
The flexibility of a system built for file transfer... this is what I'm looking for and it is difficult to describe succinctly. Is there an HTTP client as friendly and flexible as FTP as far as the mechanics of file access is concerned?
To name a few. Some of this could be implemented using HTTP/1.1, or with a smart HTTP client... but where is it? Maybe for single-file downloads and a willingness to kludge together webpages to present data, but that's not enough. It could be, but I haven't seen anything really flexible.
The flexibility in presentation and access could exist, but until it does, FTP will not be displaced, IMHO. I'd love to be proven wrong, though.
I'm familiar with the possibilities you mention for the HTTP/1.1 protocol. I even use a few of them in serving web content myself. However, I'm unfamiliar with useful implementations (on the client-side) that embrace these possibilities fully... Or even a client/server combination that builds upon HTTP/1.1 like you outline to provide a viable and actual alternative to FTP.
Enlighten me. Where's the FTP-killing HTTP implementation of which you speak? Seriously.
I don't think routing all data transfer through HTTP is a panacea... perhaps it offers better "out of the box" security than your average FTP service, but your comment smacks of the tendency to run with port 80 hashed and rehashed earlier on Slashdot.
You're comments are spot-on as far as trust and public access are concerned, I simply question the view that HTTP is a simple (and better) replacement for FTP. Obviously, FTP implementations have their issues (and *big* ones, too) with security, but to me, HTTP can't really offer all that FTP does in terms of file transport.
Please correct me if I'm wrong.
Minor unrelated peeve: why is it that Slashdot's search indexing exclude words of fewer than four characters in length? Silly... I couldn't search for XML as a keyword, and had to hope that SOAP made due appearance in the article I reference.
Seriously, there is so much out there that lofty goals fall apart for any but the smallest of niches. The original efforts of Yahoo! just couldn't keep pace with 'Net growth, leading to gridlock on entries and deletions and deterioration of its organization and review process.
A more recent attempt, dmoz.org seems to have stagnated under the weight of the Web. All of the specific sections I visit lack moderation, and are about as useful as a random web search ("Gee! I wonder where they get the initial link collections.")
Peer review is a great idea, and does take place, but requires a lot of effort and cooperation to pull off on any scale above microscopic. Been there, done that, got tired.
I hope you take into account that this was simply an informational email - and my guess is a lot of people don't know you can setup a robots.txt entry to allow one crawler but block others.
That may be, but I don't really think that's the intention guiding the email itself (see elsewhere in this thread for its possible commercial implications).
Very few people running major sites instantiate a robots.txt file (go around and look for it, as I do on occasion -- it's surprisingly rare) and those who do generally know what they're doing, mainly because the vast majority of exclusion rules you see on the 'Net apply to all robots and not a few 'bots here and there.
I doubt global exclusion, as commonly practiced, signals someone behind the scenes thinking "Gee, I don't want to exclude Google, but I simply don't know how!" (in the main). The standard is not that hard to read and follow, and as the OP -- and perhaps the relative rarity of robots.txt in the wild -- indicates one really has to want to create an exclusion file.
Till then, one email doesn't hurt...
I'll remember that for each and every spammer out there who only sends me a single email before being shut down.:)
Seriously, though, for unasked-for email, this example is relatively benign. Above all else, I find it odd and wonder whether I'll receive it soon enough. Why wouldn't Google just add more prominent notice of their own (existing) information regarding robots.txt to their site instead of undertaking an email campaign? Very odd and wasteful.
Well, the reality of the matter is that it's just not possible. Online communities just happen. If you try to intentionally build one, you are wasting your time.
Excuse me, but I call bullshit.
Online communities don't just happen. One or more individuals have to put in the effort to get them off the ground and to keep them running if and when community membership grows beyond current capacity. Period.
Groups or individuals who start online communities don't grow them by accident. Sure, there might be a few cases where it someone accidentally taps into a sublimated need for membership. But usually, people kick these things off to satisfy a need not found elsewhere. Maybe just for themselves at first, but usally with an eye toward drawing more people in. Else, why would they even let people join their proto-community?
I think you underestimate the ability to consciously build a community. I see it happen all the time when people of like interests or in similar need reach out for assistance, online and off. In the online world, next thing you know, someone has built a website, started a mailing list, maybe even started an Open Source software project (blatant moderator pap).
And organizations, whether for profit or not, can get in on this. Look at the sites that sprout up around newly released PC games. Look at how firms behind those releases may or may not wish to get involved in building community interest and providing a community roost -- wallpapers, message boards, members-only material, insider reports. Those all build forms of community.
And look what happens when they drop the ball -- I'm thinking of Derek Smart and his handling of BC3K types, of Firaxis in the past in handling their message boards (and I think pulling them entirely in the end?), and so on. That's when companies and individuals learn how strong their communities have become. I'm certain others can come up with far better examples of communities nursed or spurred into existence at the hands of business.
And if you think AOL has failed to build an online community, I don't think you've ever really talked to people who represent their die-hard userbase. That, or you've never heard of AIM. Now *there's* an online community that AOL taps time and time again with banner ads...
You are right, though, that throwing money at a problem or in support of a perceived business need isn't a solution in and of itself. But to say that community building is somehow anathema to financial concerns or beyond-the-niche support is mistaken.
Besides, what do I need 8 megs of memory for? I don't know 8 megs worth of people or send 8 megs worth of e-mail.
Eight megs of applications beyond the system-standard set, eight megs of reference materials and data stores... you'd be surprised how skimpy two (or four) megs actually are when trying to get thorough use out of palm[-like].
...about things like digital rights. The CNN piece clearly states in the first paragraph:
The system promises fewer computer crashes and will allow users to delete data from their hard drive.
That's should satisfy everyone, right?
Re:Portable N64 are not unlikely
on
Portable N64
·
· Score: 1
And with GBA coming out, that is capable of having many NES, SNES, and N64 games ported to it [...]
The
Game Boy Advance has been available in the States since June 11th. No idea where you've been since then, though I must admit to being a bit curious.
this is precisely why I am up in arms about that kind of research: because, to them, I am "just a number."
You must really have a problem with the census, then, and all the benefits that arise from it and other forms of social research. Intelligent marketers want to achieve the same goals as with any social research project - learn as much as they can about target populations as accurately and efficiently as possible. In the case of marketers, so they will know who best to peddle their wares and what wares will sell best.
The leap from statistical analysis of populations to the privacy concerns you voiced is a large one. Why moderators continue to confuse slippery slope arguments with true insight is beyond me.
"Oh, boy!"
This is the first, and likely last, time I will write a "MOD THE PARENT UP" post. But damn, it's funny. Anything to throw in a media reference that *isn't* borrowed from the Simpsons.
If this isn't a reason for Slashdot to ditch its crufty, table-laden markup for a modern, svelte approach to layout ... well, I don't
know what is.
SlashdotLite isn't the solution. I'll even let Malda et al. keep their tables, just cut down on the cruft.
It's a joke. Laugh.
This is the funniest thing Bill Gates has EVER said.
Guess what? Google doesn't cache images!
The only problem remaining: Getting the monkey to understand where you want to move the mouse.
While none of them were as badly written as the "C" article, none of them were well edited, and all contained basic gramatical and spelling errors. In other words, here's a magazine I won't be reading again.
Throwdini the Great thinks:
Cliffom could have saved 78 characters by simply writing: "Me, too."
*rimshot*
Just have the browser request the image minus the prefix; the server can then choose what type to send
Who will be most upset by the @home outage?
[N]ote that HTTP has one feature over FTP that I forgot about until now. Content-type!
What? You've never tried to go to a page and been presented with a pop-up box asking you for user and password for such-and-such an authentication domain?
HTTP defines the "Auth-Type" header, with the two commonly supported methods "Basic" and "Digest" (the latter does not send cleartext passwords).
Several command-line http clients implement "reget" functionality using the "Range" or "Byte-Range" (whatever it's called) HTTP header, which I think (but am not sure) even /1.0 supports.
Most web browsers... (x3)
both require a new connection for each dir listing or file transfer - except HTTP/1.1 which can reuse a connection. HTTP wins.
FTP requires an additional TCP connection for the control info. More setup and teardown cost. HTTP wins.
Many sites are already running an HTTP server, so using that for file transfer means one less daemon. Mitigated by running ftpd out of inetd, which most people do, but still ... HTTP wins.
HTTP can use auth methods other than plaintext, and can easily have different sets of auth'd users in different directories
What are the advantages to FTP for downloads ... I honestly can't think of any ATM.
HTTP really is all that.
For outgoing data, you can just use HTTP.
It'd be good to see something resembling peer review on the web after all.
I hope you take into account that this was simply an informational email - and my guess is a lot of people don't know you can setup a robots.txt entry to allow one crawler but block others.
Till then, one email doesn't hurt ...
Well, the reality of the matter is that it's just not possible. Online communities just happen. If you try to intentionally build one, you are wasting your time.
I duel boot between linux ... and Windows...
Worst. Thread. Ever.
Besides, what do I need 8 megs of memory for? I don't know 8 megs worth of people or send 8 megs worth of e-mail.
...about things like digital rights. The CNN piece clearly states in the first paragraph:
That's should satisfy everyone, right?
And with GBA coming out, that is capable of having many NES, SNES, and N64 games ported to it [...]
this is precisely why I am up in arms about that kind of research: because, to them, I am "just a number."
Ummmm, the only actually grammatical problem was the "dispite" thing.