On Friday 18 January 2008 18:07, you wrote: > On Jan 15, 2008 1:57 PM, Matthew Toseland <toad at amphibian.dyndns.org> > wrote: > > TOTALS: > > Essential: 5 weeks 3 days > > Important: 10 weeks 3 days > > Good to have: 32 weeks 2 days > > I am of the view that the good-to-have features can be safely postponed for > > 0.7.1 or 0.8. IMHO it would be good to have at least some of the features > > marked Important. > > We can't wait another year, or even half a year for 0.7.0. Think > about it, Oskar and I presented our design for 0.7.0 back in July > 2005, two and a half years and we are still a year away from a point > release? Its ridiculous, we should aim to release 0.7.0 in or before > March 2008 - and we should cull any features that threaten to push us > beyond that.
Quality makes a releasable product, not time. If time is the most important thing we should have a fixed semiannual or annual release cycle with date based versions, as Gentoo for example does. But if we control the schedule for maximum impact a major milestone release should be of reasonable quality: opennet on its own isn't enough, we already had that in 0.5. Did you read the bit at the end? The good-if-possible [2] stuff isn't essential for 0.7.0, but IMHO we should keep *some* of the important [1]s. > > > Big stuff: (5 weeks essential, 5 weeks important, 15 weeks good-if-possible) > > > > [0] Enough seednodes to survive a MAJOR slashdotting. That probably means some > > form of auto-harvesting. (1-3 weeks) > > Not if people step up and provide our seednodes. So far we have 12. I hope this will be adequate and we won't have to do any work on auto-harvesting, really I do (not least because of the need to learn php!). > > > [0] Ultra Lightweight Passive Requests. Essential for web of trust based chat > > applications, and generally useful. (2 weeks) > > No way is this essential for 0.7.0. I beg to differ. No network will survive without chat. The big killer app for the internet is and always was email. A community requires communication. Now, I don't see any reason for me to write a single line of code on Frost, but ULPRs are essential for the next generation of spam resistant chat clients. It will be interesting to see the reaction to the spam problem when we release alpha 2 - it's insidious, people will assume Frost just doesn't work (on most of the default boards) because most of the spam isn't visible. We should probably mention it in the alpha 2 announcement. > > > [1] Finish Echo, or customize and bundle thingamablog (1 week) > > Not even sure what this is. http://thingamablog.sourceforge.net/ An easy, complete, GPL, Java-based blog engine. Echo on the other hand is one of our summer of code projects with more or less the same goals - an easy blog creator. Currently Echo works but isn't bundled because of build complexities. The point here is simply to have a way to publish content and especially blogs *EASILY*. Having to load up Frontpage isn't easy, it's work. Nobody has their own website any more: geeks sometimes use local blogging engines, and everyone else uses big corporate blogging tools. > > > [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) > > Why on earth is this a precondition for 0.7.0? Because the current code's security is rather poor, because *something* in this region (not necessarily full blown tunnels) should be a relatively easy improvement, and because we need to be able to honestly say 0.7 is an improvement in security on 0.5. Now, superficially this is true because of the diffie-hellman weak keys bug, although that has been fixed on 0.5 also and was fixed in Tor two years ago; it's true because of darknet, but nobody uses it; there are numerous minor improvements, but on the other hand, we do a lot more requests for a file, and each request arguably gives away more information than it did in 0.5 (hi to all you folk reading this on slashdot/frost!). So if we can for example switch from HTL to a simple weighted coin (one of the proposals under discussion), that would be easy to implement and might improve security significantly. Full blown tunnels would definitely improve security against a distant attacker, although they would likely take some tuning to get right. Postponing full tunnels to 0.7.1 or whatever may be a good idea, but if it turns out there is something *easy* we can do that goes half way, we should do it. > > > [1] Make big sites work well (multiple container inserts) (2 weeks) > > Same question. Content is king (after messaging!). Interesting sites are often big sites. > > > [2] Full download resuming (2 weeks) > > No way we need this for 0.7.0. That's why it's [2]. I'm sorry I wasn't clearer, I should have mentioned that at the top, although "good to have" does rather imply it's not enormously important. > > > INSTALLER(S): (1 week good-if-possible?) > > [2] Linux packages. (??) > > [2] Install a startup script on Linux. (1 week?) > > We do need to ensure that installation is easy and people can get from > downloading to using Freenet as easily as possible. I would give this > a [0] priority. Even on Linux? I'm happy to look into it; nextgens has done some work on it. > > > 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) > > None of this is a prerequisite for 0.7.0. Well, a Search Freenet! box would be a mind boggling feature for the typical tried-freenet-years-ago-it-sucked user, that's all... and it wouldn't be a lot of work. > > > NETWORK PROFILING: (3 days important) > > [1] Simple threaded probe requests. (3 days) > > Ditto. We can drop this if need be. > > > FPROXY: (1 week important, 3 weeks good-to-have) > > [1] RSS filter. (important for blogging) (3 days) I listed this as Important because it's important to blogging. Blogging is 80% of user generated content on the web now i.e. it's fairly important. OTOH if we don't include a blogging engine the priority is greatly reduced. > > > 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 might drop this to [1] - I'd be willing to ship without it, but it does mean we will have significant, backward incompatible changes to FCP later on. > > [1] Much less disk space usage for uploads (various optimisations). (1 week) I've done about half of this already. The second half may be harder though. It's important but not essential. > > [1] Don't report internal error on an invalid key. (1 day) This is trivial, I will do it today. Sorry for the clutter. > > DATASTORE: (1d important, 1w4d good-to-have) > > [1] Datastore histogram. (1 day) IMHO this is important verification that we have a routing problem (the datastore specialisation as measured by the stats code is nowhere near the actual node location on most nodes). > > > 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) Fproxy is now capable of inserting freesites, although admittedly it's not a great interface. It will do well enough for the geeks/relatively dedicated users uploading huge sites who have outgrown jSite in its current state. > > > [1] ULPRs are essential for any spam-proof messaging system. We should give > > the Frost devs any *reasonable* assistance e.g. architecture review. > > I'm ok with giving the frost guys what they need to solve their spam > problem if its easy, but once we provide the functionality, it is up > to them to fix it, we aren't fixing it, and we aren't waiting for them > to fix it either. > > > TEMP FILES: (1 day important) > > [1] Split temporary files into subdirs. (1 day) > > Nope. Like I said I'm willing to lose some of the things I marked as Important. > > > 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. > > - AVI, PDF, MP3 filters. > > - Transport plugins. > > - Polymorphic UOM-based micro-installer. (nextgens) > > - Client layer coalescing. > > - Faster FEC decode especially on AMD64. (nextgens) > > Wow, I'm surprised that there are a few things that *aren't* a > precondition for 0.7.0. I apologize again for the lack of effective communication on this thread: I did not mean to make [2]'s *prerequisites* for 0.7. > > I think we really need to change our perception about timeline here, > you are sticking features in here as requirements for 0.7.0 when there > is no *way* they need to be requirements for 0.7.0. We should be > aiming to release 0.7.0 in March 2008, and we should cull features > until that becomes realistic. What happens in March? Two months ago told me you had no principled objection to doing some simulations of new load management algo's post opennet and pre 0.7.0. I'm currently working towards alpha 2, which is mostly a matter of debugging and some UI tidying. I hope to be in a position to release alpha 2 within a couple of weeks at most - so lets call it February 1st for alpha 2. Maybe even early next week if it goes well. What's the logistical plan? Alpha justifies changing the web page, but not announcing to announce at fp, and not actively soliciting a slashdot? > > Ian. -------------- 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/20080118/8b4e4797/attachment.pgp>
