On Thu, Nov 21, 2002 at 09:57:25PM +0100, panamerica334 at uni.de wrote: > hello there. > > the topic of "tying freesites together" is very interesting for me, because i > personally think, getting only half of a site just sucks ;) > > have you ever had a look on the freesites out there in freenetland? they have > nearly always > - white backgrounds, are > - designed with tables and bgcolors to make something colorful > - have just small cliparts and neary lost looking graphics embedded > > and why? > > because nobody wants to make up a freesite which can compete with "mordern" > internet sites, which consist of 30+ small graphics for a smooth look, 10+ > larger logos or banner and 5+ different backgrounds on different pages. > > if you upload such a site, then you can be sure, that there will be nothing > left the next day or you site will just look plain ugly, hving white blocks > of missing > graphics all over the place. That is not correct. Have a look at the Eternal Dilbert Archive. Eventually, all the images will load. Same goes for Propaganda Booster. There are image heavy sites out there. > > so my vote is PRO jar sites > > but how to make them up? > we have seen the complications, a small breakdown: > > * every file of the site is inserted separately > pro: CHKs collide, nothing is duplicated > pro: state-of-the-art > contra: at least one file gets lost sometimes > contra: you have to wait.. to wait and to wait if you enter another html file > belonging top the site, until fred fetches this single file out of freenet > > * the whole site is insertes as an single atomic site (or maybe two, one site > and one d/l section, whatever) > pro: you have all the stuff, without missing a small gfx, in one run if you > manage to get the jar or the fec'ed jar > pro: smaller download times (to prove :) > contra: redundancy if you change the content > contra: DBRs will get huge and due to not-colliding-CHKs will pollute the > freenet > > so, why not combine these two aspects? > > an example how to do this with a DBR site with NiceGraphics(tm) : > > 1. design your site, make it look nice, pump as many gfx'es into as you can ;) > 2. now bundle all "common" graphics, such as your "next" button and your > "top" button and your site's logo, your titleframe (html) and any other stuff > into a > .jar, e.g., mycommon.jar > 3. upload this file as a "oneshot" chk (or ssk) file, maybe even edition > based if you prefer > 4. then insert your main page(s) as a DBR like usual, changing the URIs of > the files you pu into the .jar above into the ZIP@ , ...//mycommon.jar/ or > whatever notation there will be > 5. upload the map file, which lists all files inserted under 3 and 4 > OK. Proposal: Currently manifest sites use Redirect.Target=<some key> or DateRedirect (which has .Increment, .Target and .Offset). Add ZIPRedirect: ZIPRedirect.Target=<some key, which is a ZIP> ZIPRedirect.Filename=<filename within zip to extract>
Another way to handle it would be to have a ZIP keytype, but if that is to be fully generic it becomes messy. Maybe ZIP@<SSK key>/[/]<filename> and ZIP@<CHK details>,<second part of CHK details>/[/]<filename> Another point: we should support something like HTTP's Content-Transfer-Encoding: gzip, if it's reasonably easy to do so. Example: Version Revision=1 EndPart Document ZIPRedirect.Target=CHK at blah ZIPRedirect.Filename=blah Info.Format=text/html Document Name=blah2.txt Redirect.Target=CHK at blahblah Info.Format=text/plain Encoding=gzip End > viola... > > if you change your site's main page, you upload the DBR and the map file, but > reuse your oneshot mycommon.jar which contains all graphics needed for the > layout of your site > > if you change your layout, make a new mycommon.jar bundle, upload it under a > different CHK or use the edition system, adapt your main page and upload > the DBR as usual. > > so you get: > * your graphics as have-it-or-loose (you will have it, as it is a single file > which will spread *VERY* goot, because it is needed every time an user visits > your > site, unless you change your site's layout) which will save your layout and > will not produce any white blocks in your frenet appearance > * your main page, as usual as a DBR, so always up-to-date > * the chance to change your site's layout and everything you have to do is > simply bundle up a new "visual theme" of it an upload it somewhere, adapt > your > sites and let the old layout drop off the network (old sites will work, too, > but without everything you stuffed into the old archive, but as these are > spread very > good, old themes will work for a very long time until they fall off the > network) > * you also can bundle up special sections of your site (which will not change > so often, but they *may*) into a .jar > > so you load specific "modules" of your site. this will, rough guess, be 10 > .jar files containing gfx, support files, other site pages which concern a > specific > topic. and your DBR main page if you wish, together with other DBR files you > want (today's picture, e.g.) > > bunding up files makes a site which will consist of 150 files to a site with > 15 files, and the often used "site modules", such as gfx, are spread very > well > because they are often requested, and IF one .jar drops, this will surely be > a part of your site nobody looks at (downloads, my favourite pets, e.g.) but > these > can be bundled up quite nicely into a single .jar (the all-or-nothing > approach, what use is it, if the html files is missing but all graphics could > be retrieved?!) > > don't forget .jars are compressed, so all your html files will get smaller, > too > > comments? > > >Sorry people... are you actually proposing inserting the same files over and > >over? Because you are! You are actually polluting freenet this way by > >introducing redundancy of the worst kind: blind redundancy > > > >Freenet is efficient storage because every unique piece of data (in the file > >level) has a related CHK key so that the system knows what is already in > >there. Packaging stuff into compressed files, for whatever reason, hides the > >data, introducing useless new CHK keys that claim space for the compressed > >file, which is actually partly, if not mostly, the same data. > > > >Imagine a "typical", let's say 1MB, DBR site re-inserted every day, even > >though only part of the content is altered (i.e. graphics, which should be > >the larger part in size, stay the same, but the html changes). Poor usage of > >the capabilities of freenet, wouldn't you say; > > > >There is indeed a need to improve speed (try saying that 10 times, fast), > >but let's not break freenet, OK? > -- Matthew Toseland toad at amphibian.dyndns.org amphibian at users.sourceforge.net Freenet/Coldstore open source hacker. Employed full time by Freenet Project Inc. from 11/9/02 to 11/1/03 http://freenetproject.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20021121/b8698c15/attachment.pgp>
