* Matthew Toseland <toad at amphibian.dyndns.org> [2008-01-15 19:57:47]:
Ok, let's chime in as noone else does... I won't comment on time-requirement evaluated by toad: only on the priority ranking. > [0] Enough seednodes to survive a MAJOR slashdotting. That probably means > some > form of auto-harvesting. (1-3 weeks) I'm not convinced that we need auto-harvesting at that point... Depending on how big the network gets with rcs and alphas we will see... but keep in mind that bundling a *large* file doesn't make sense either. > [0] Ultra Lightweight Passive Requests. Essential for web of trust based chat > applications, and generally useful. (2 weeks) I'm not convinced that implementing that hack contributes to make any step forward... as it will harm "real passive requests" on the long run. If we do it we *need* to do it soon. > [1] Finish Echo, or customize and bundle thingamablog (1 week) I would give a higher priority to that task. We release to get more users and more specifically more content: releasing before we have decent insertion tools doesn't make much sense to me (jSite can't handle persistent requests, pyfreenet doesn't support testdda, ...) > [1] Tunnels. Michael Rogers and I have had some fruitful discussions about > security, it looks like some form of (optional) tunnels may greatly improve > security at little code cost and some performance cost. (2 weeks) I would decrease the priority of that one (on the basis that we can't higher all priorities). It wasn't on the roadmap a few weeks ago... we can probably wait a bit for ideas to settle before we implement it. > [1] Make big sites work well (multiple container inserts) (2 weeks) > [2] Full download resuming (2 weeks) I'm opposed to having that implemented at all. Now that the database is preserving the LRU table I don't see any good reason why that should be implemented. We need incentives for users to keep their node running. > [2] Plugin versioning and auto-update-over-freenet (1 week) > [2] Finish API and implement the new plugin system (3 weeks) I regard it as an important piece of the puzzle. IMHO we need APIs to be "frozen" before any release so that 3rd party apps can be built. > [2] Simulate alternate load management schemes, and deploy (4 weeks??) > [2] Low-level rewrite (packet format, congestion control, etc) (3 weeks?) > [2] Datastore rewrite (to use any SQL engine e.g. Derby, or external e.g. > mysql), some people have been having major problems (2 weeks, I'd like to > postpone it, if it behaves I will) I'm still awaiting for proofs that it's useful. No relational database can have better performances than BDB... and I don't see why they would be more corruption proof. > > Other stuff: > > NODE: (2 days good-if-possible) > [2] Per-node failure tables / route around nodes that fail for a specific > key. > Easy extension of ULPRs. (2 days) > If we implement ULPRs it's a must have imo. > INSTALLER(S): (1 week good-if-possible?) > [2] Linux packages. (??) > [2] Install a startup script on Linux. (1 week?) I would put [1] here... but it's far from being a simple to solve problem. > XMLLIBRARIAN: (1 week important, 3 days good-if-possible) > [1] Integrate cleanly and easily with freesites. (2 days) > [1] Search box on home page. (1 day) > [1] More usability work (All Indexes folder, etc) (3 days) > [2] Adjacent word matching support. (1 day) > [2] Filtered HTML in summaries. (1 day) > [2] Negative match support. (1 day) > I regard Librarian as a 3rd party software... and would assign at most 2 to all of those tasks. > NETWORK PROFILING: (3 days important) > [1] Simple threaded probe requests. (3 days) > I do think that those would be useful... and that they should have been implemented a while ago when the network topology was simpler (before opennet and the periodic location randomization thingy). > FPROXY: (1 week important, 3 weeks good-to-have) > [1] RSS filter. (important for blogging) (3 days) > [2] Rewrite CSS2 filter (better standards support, better security). (1 week) > [1] Support XHTML 1.1, 2.0, HTML 5.0 (3 days) I would put 2 here as well > [2] Support SVG including embedded in XHTML. (1 week) > [2] ogg vorbis, ogg theora filters (1 week) > > CLIENT LAYER / FCP LAYER: (3 days essential, 2w3d important, 4w1d > good-to-have) > [0] TestDDA working and mandatory for direct directory uploads. (3 days) I never got around implementing something for directories because we never agreed on how that should be done :) I don't regard it as urgent nor must-have as no tool is currently using TestDDA as it should (and no fcp client author has expressed the need of such a functionality) > [1] Much less disk space usage for uploads (various optimisations). (1 week) > [2] tar.gz support for packing containers. (2 days) (ASL2 licensing issues) > [2] tar.bz2 support for packing containers. (2 days) (ASL2 licensing issues > with .tar) > [2] Or use cpio or something to avoid licensing issues. (2 days) > [1] Fix >2GB uploads (2 days) As I told you on IRC that's a must have. Freenet is likely to perform way better on "large" files as the impact of latency will be reduced... And that's good for benchmarks/publicity/credibility. > [2] Revocable Subspace Keys and an official project freesite (1 week) I do regard that as important too. Would give 1 there. > [2] Fix implicit containers subdirs support. (2 days) > [1] Don't report internal error on an invalid key. (1 day) > [2] FCP API for Node to Node Messages so Thaw etc can talk with Thaw on > nearby > darknet nodes. (3 days) > [1] Cut disk space usage *significantly* in uploads. (1 week) > [2] Client-cache. (3 days) > [2] Redirects to USKs. (1 day) > [2] Insert-time charset detection. (2 days) > [2] Memory optimise splitfile inserts as did with requests. (4 days) [1] provide a "content hash" in the manifest of splitfiles so that they can be compared > > FROST ETC RELATED: (2w good-to-have) > [2] ?filename= parameter to fproxy/clients, so we can go back to CHK's being > invariant for different filenames. (2 days) > [2] Enforced whole-file hash and prevent DDA data from changing during > insertion. (1 week) I would raise the priority of that one as it can lead to incomprehensible bug reports. > [2] Selective reinsertion / indicate what blocks can't be fetched. (3 days) > > DARKNET: (2w4d good-to-have) > [2] One-time invites. (4 days) > [2] Short-noderef invites. (1 week) > [2] Distribution mechanism - installer-invite-bundle generator. (1 week) > > DATASTORE: (1d important, 1w4d good-to-have) > [2] Better datastore shrinking, on the fly with accurate LRU. (3 days) > [1] Datastore histogram. (1 day) > [2] Option to encrypt datastore. (3 days) > [2] Option to put temp files in datastore. (3 days) > [2] option to put persistent requests in datastore > CLIENTS: (~~ 1 week good-to-have) > [2] We should have some sort of client that supports uploading freesites > persistently. Bombe was going to fix jSite to do this. If not that, then > maybe a WebDAV plugin. (1 week for webdav plugin) IMHO That's a must have for a release ... we need content... and that's also the point of releasing. > [1] ULPRs are essential for any spam-proof messaging system. We should give > the Frost devs any *reasonable* assistance e.g. architecture review. > You've already put that one at the beginning... my position still stands; either soon or never. > LINK LAYER: (3 days good-to-have) > [2] Debug not-forwarded-detection and turn off assumeNATed by default. (3 > days) > > TEMP FILES: (1 day important) > [1] Split temporary files into subdirs. (1 day) > I would lower the priority of that one unless there is a reason I'm missing. I'd rather integrate them to the db than spending time creating YetANewCustomStorageFormat. > > Postponed for 0.8: (unless somebody does it before that) > - Premix routing. > - Full passive requests. > - Swapping must resist an active clustering attack. > - Better support for fragmented networks. > - NAT-PMP plugin. Well, I would rank that one [2] and wouldn't postpone it. > - AVI, PDF, MP3 filters. > - Transport plugins. > - Polymorphic UOM-based micro-installer. (nextgens) > - Client layer coalescing. > - Faster FEC decode especially on AMD64. (nextgens) I hope that helps. NextGen$ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20080117/0847c5f4/attachment.pgp>
