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. 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 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? ____________________________________________________________ The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. _______________________________________________ support mailing list [EMAIL PROTECTED] http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/support
