> > I fear that your approach, while I am sure it is an improvement over > > what we have now, it is a further step along the alchemy path - away > > from the true and non-arbitrary path of NGrouting ;-) > > While there is alchemy in my changes, there is less than in the current > code.
I don't disagree - but the question is whether it is more productive to work on code now that will be replaced in a few weeks, or just get on with NGrouting itself. > > The idea of NGRouting is to have a consistent way to integrate all of > > the information you talk about in a non-arbitrary and easily tested > > manner - namely by combining all available information (including that > > which your changes uses) into a single estimated routing time. This way > > we aren't just arbitrarily combining this information. > > You have two types of routing to consider. Non cached non cached. How > is it planned to have NG routing handle this? > This is the biggest piece of alchemy in my changes. Its also something > that has a very good effect - without this nodes with lots of references > are dropped as quickly as nodes with one or two. Think NG routing will > benifit from something very much like this. NGrouting will, in a sense, figure this out for itself - hopefully we won't need to use alchemy to force it to happen. > Actually the origin version(s) of my changes used a kalman predictor > to calculate the next CP. But even the CP itself is alchemy. Requests should be routed to the node which is likely to result in the lowest request time, and CP is an extremely crude way to take this into account. Ian. -- Ian Clarke [EMAIL PROTECTED] Coordinator, The Freenet Project http://freenetproject.org/ Founder, Locutus http://locut.us/ Personal Homepage http://locut.us/ian/
pgp00000.pgp
Description: PGP signature
