On Fri, Jul 25, 2003 at 08:05:39AM +0100, Gordan wrote: > On Friday 25 July 2003 03:06, Tom Kaitchuck wrote: > > On Thursday 24 July 2003 06:58 pm, Gordan wrote: > > > In that case let's limit it to 64 KB or 128 KB. It's still a cludge, but > > > at least the damage is kept reasonably small. 1MB is just ridiculous. > > > > My understanding is that 1MB was picked, just because it was as large as > > you could go in a single key.
Someone picks an arbitary value that someone else dissagrees with. News at 11. It is highly likely, btw, that my modem is as slow as or slower than yours. (hey, i thought you were supposed to go bigger in these contests :-p) > > > > If it is done like I describe, how is there ANY more unnecessary > > > > traffic than before? > > > > > > Active links from other sites? I don't necessarily want to go and see all > > > the sites that have active links on another site, for example. And you > > > are increasing the amount of traffic that active linking would generate, > > > from just the active link to the active link plus the front page plus > > > potentially more data. Imagine how much extra bandwidth you will waste > > > every time somebody goes to visit one of the index sites. > > > > > > I know that you disagree, but this is not a sensible trade-off. > > > > No, I don't disagree. I previously stated that images that are intended to > > be used as active links should under no circomstances be zipped. > > OK, can you give an example of a Freesite (or create one that specifically > suffers the problem that ZIP files would aim to solve, for the purpose of the > demonstration) that would benefit from this approach in a demonstrable > fashion? Fishland 2.0 would have, by virte of having a lot of small html keys (over 200keys of 1k or less, and over 500keys total). Although Fishland|3 d oens't as much, it also would benefit from containers in the same way. Colours is completly pointless unless his HTML and CSS are together, unless the only colour in your world is white/grey. TFE's usability would significantly benefit from users not getting stuck on that damn warning page, if the warning page and thelist.html were in a single container. Keeping lots of small HTML files refreshed is a hellish experience, and one that I look forward to avoiding in the future. (yes, yes, i know, incorrect use of freenet, should modify content to fit the network, not vice versa, blah blah blah. I've heard it before, and let me assure you that the answer is foad. :) > And what happens to those of us who are interested only in textual rather than > image content? You contine using lynx/links/w3m as always? The piece of perspective that you are missing, is that on the sites that you want to visit, the images are a tiny part of the size of the site anyhow. Never underestimate the bloat of HTML :). > Additionally, images are not indexable. If there is somebody out there who is > working on an automated indexing robot, then this robot would put more strain > on the network than necessary if it starts retrieving ZIP files with images > in them because those images would not be used by it. http://images.google.com. > Proper automated search facilities will eventually be required, and making > them more difficult or more wasteful to implement now will only come to bite > the network later. > > > I am not at all convinced about the user experience argument. > > > Additionally, a "huge page with links" will become nigh-on impossible to > > > use sensibly if for each active link you have to download the whole > > > linked site. See point above about index sites. > > > > If you don't zip active links this is a non issue. > > I think this should be extended at least to all images, rather than just > active links, if we DO end up with having archives. HTML pages only, and > limit the size to much smaller than 1 MB. > > > I still don't think it is a worthwhile tradeoff. There will always be > > > cases such as NIM that will make sure you cannot defeat the problem > > > completely, and the gain just doesn't seem that great. Where is is really > > > deemed necessary, manual pre-caching using IFRAME tags and automated > > > pre-caching using specifically designed software for the purpose are IMHO > > > a better solution. Using archives simply isn't the correct tool for the > > > job, as far as I can see. It is a very ugly exception to the way Freenet > > > is supposed to work. > > > > Well, things like NIMs wouldn't be zipped. MOST of the content on Freenet > > SHOULD NOT be zipped, and if it is done right it won't be. However there > > are places where it could help. Could you explain exactly what you mean > > when you say "manual pre-caching" and "automated pre-caching". > > Manual pre-caching would be using IFRAME tags to pre-load pages/files that the > page links to, so that while you are reading the current page, the pages you > are likely to go to are already pre-caching. Which is a horrible, horrible nasty hack. > Automated pre-caching would be using pre-caching software than automatically > follows all links from the current page and puts them in your browser cache. Which is really, on the whole, no better. Putting what is is baiscally only really a good idea on freenet into a general purpose webbrowser is not a good idea. At some point, you have to deal with the basic fact that freenet works differently. Alternatly, having external software fuck with your browser is never a good idea. Having this implented as a FCP based client will interact badly with pcaching (do NOT turn this into a pcaching rant. I don't care.) > The latter, although far less than ideal, would IMO still be better than > implementing archives on the node level. Obviously, I disagree with you. > > > That doesn't really call for a ZIP at all. You can just upload each file > > > by the CHK, but in that case, you could make an edition type site that > > > you could use for the "skins". > > > > Yes that would work, but it would be slow with high latency. Even if the > > latency were as low as the WWW it would not really be good enough to do > > this sort of thing. Having zips would allow you to have dosens possibly > > hundreds of VERY SMALL images on a site as part of a theme. > > OK, for the first time there is an aspect of this that I might actually be > able to swallow as vaguely sensible. But again, the same problems are there: > > 1) There would be no way to automatically decide what should be in an archive. actually, I have ideas on how to do exactly this. I just don't have time to implent them right this minute. But, in short, you can do a depth first or breadth search of HTML files, and create new archieves when you hit siteLimit, resetting to the top of the tree if you're using depthFirst searching. You then do the same with any images of <64kbytes. Mess up the HTML links to match waht you just wrote, and you're set. > 2) Allowing it to be done manually would allow for "abuse" of the network by > bandwidth wasting Allowing anything would allow for abuse of the network, and does. Allowing for splitfiles allowed people to flood the network with moivez. Allowing for CSs allows people to create pages that aren't 100% compatable with netscape. Allowing for bookmarks from HTML allows people to fool others into showing their link on the front page. Allowing inserts leads to abuse. Yes, there needs to be limits. But here's the big secret: If you do something stupid, your page will be nigh on unretrivable (despite the fact that it shouldn't be, for various reasons that I don't really know enough about to comment on intelligably, larger keys are more difficult to retrieve than smaller ones). And then no-one will view it. And then it will drop off the network. Darwin wins again. > 3) Doing it manually would likely be beyond most people's abilities to do > properly. It is a bit like shooting yourself in the foot with a rocket > launcher. You severly underestimate a normal person's ability to operate winzip. > While this use (skins) would probably be OK, it would still be likely to > create more problems than it solves, and good CSS is probably a better way to > go than graphic heavy skins. > And besides, latency with parallel downloads is not really an issue, as the > latency for each download is suffered simultaneously, not in series. This is indeed true. But what *is* a problem, is latency *between pages of a single site*, i.e. when you click on the next page of an extended article, for example, five minute wait. oh joy. Containers aren't perfect. They aren't even a good idea. But so far, you are yet to come up with a better one. -- fish
pgp00000.pgp
Description: PGP signature
