> > * Searching > I have a reasonably solid proposal for this which tackles the issue of > routing searches, frequently glossed over in other proposals. I don't > claim it is perfect, but it is a start I think this still needs a *little* more thrashing about. But we've more or less agreed only that the search keyspace is independant from the data keyspace, and that using fuzzy logic on the *collection* side of the search is a good thing.
> * Unrequests > I think [hope] that everyone is happy with this now, it should be > reasonably straight-forward to implement Probably. > * Simulation > Oskar has done some good work on this Oskar and I are going to be working heavily on this in June. > * Updates > This proved to be a thorny one, and we will probably need the simulation > to decide on the best way to do it Yep. > * Protocol issues > There is much discussion on the dev list about the protocol - this seems > to be coming up with sensible ideas, so I think that is progressing ok > already. I'd like to come to an agreement on this as soon as possible, as everything else really depends on this. > > I am minded to create separate mailing lists for each of these, and to > invite people to join them as teams. Segregating people like this > should help avoid the "too many cooks..." problem which I think has been > causing problems recently. Well, maybe. Search definitely could have its own list. Updates really probably don't need to (they're not a very hard problem once we get around to agreeing on one). Protocol probably will be very low traffic, no offense Lee. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20000518/efd5f48c/attachment.pgp>
