On Thursday 24 July 2003 09:14 am, Gordan wrote: > On Thursday 24 July 2003 14:43, Kevin Steen wrote: > > >Call me skeptical, but I think this is an amazingly bad idea. It > > > removes any concept of having redundant date de-duplicated > > > automatically. Also, downloading 1 MB file will potentially take quite > > > a while. Smaller files can be downloaded with a greater degree of > > > parallelism. I am simply not convinced > > >that partial availability is a problem with a properly routed node, and > > > that is all this will achieve. In a way, I think this will make the > > > problem worse, > > >because if the entire file cannot be retrieved or re-assembled, then > > > the whole site is unavailable, rather than perhaps a few small parts > > > of it. > > > > Supporting containers allows freesite authors to make the decision for > > themselves, with the 1MB limit preventing drastic duplication on the > > network. > > I am not convinded that this decision should be left to the author. If they > are that concerned about it they can upload the ZIP of the whole site > separately themselves and give link to it. At best building it into the > node is a bodge, and at worst, it is counterproductive. What happens when > the same files are linked from multiple pages, e.g. active links? Do you > bundle the files separately into each "archive set"? Where do you draw a > line? > > > I see the main use for containers being to keep the _required_ > > parts of a freesite together - namely the html files, layout images, PGP > > key and Activelink. > > Except that for a site with more than 2 pages, this becomes extremely > cumbersome to separate manually. An automated approach could be used by > analysing html and linked documents, but this has other limitations, such > as how do you decide how to separate the files into archives? What about > when you have to put one file into all archives? How difficult will it be > to come up with "auxiliary" archives that have files accessed from multiple > pages? > > It is logically incoherent, and cannot be dealt with in a way that is both > generic and consistent. Therefore, I believe it should not be catered for, > especially as it doesn't add any new functionality, and the benefits it > provides are at best questionable.
This is not true if all the Freesite insertion utilities do it properly. Toad said that it only supports up to 1MB after compression. This means that the entire container will ALWAYS be a single file. (Never broken up into chunks.) The proper way for utilities to handle this, IMHO, would be to put all the HTML into one container. If it doesn't fit, or doesn't have enough "headroom" for edition sites, split it based on depth, so that there are two zips about the same size. Then make a separate zip for images. The only images that should be included are those that appear on multiple pages, or on the main page, excluding active links. They should be sorted biased on size and then only the smallest 1MB worth should be zipped. There in never any real reason for a single edition site to have more than one image zip. Then for dbr and edition sites, the utility should save a list of the files that were previously zipped together. This way it is sure to do it the same way every time, and it can add another zip if there are enough new images. If this was done by the insertion utilities the user wouldn't need to know anything about how the zipping worked. _______________________________________________ devl mailing list [EMAIL PROTECTED] http://hawk.freenetproject.org:8080/cgi-bin/mailman/listinfo/devl
