On Friday 11 January 2008 20:15, David Sowder wrote: > I'm using N2NMs as a generic message type and I thought you were cool > with that after our earlier discussion about differential node > references. Because of this, I don't assume all functionality of N2NMs, > as only previously used by N2NTMs, to be darknet-only. As for own > routing on top of Freenet, that's one of the things I've been wanting to > play with once I got N2NMs into FCP. My current assumption, and my > implementation reflects it, is that queuing a N2NM for an opennet peer > doesn't make sense because we have no idea if we'll ever re-connect to > that currently disconnected peer. > > So the simplest solution is to always queue, to only allow N2NMs to/from > > darknet peers, and to have a separate message type for the low-level > > mechanism of differential noderefs (which can of course share code if there > > is any major code to be done). Is the simplest solution the best in this > > case? It seems like premature complexity to me - but maybe it's useful > > complexity? > > > I don't always queue because queuing is only needed for disconnected > peers, though I supposed we could sendAsync it and then the connection > dies before it's delivered. > Currently, I like the idea of N2NMs not being darknet-only. Sure we > could say they are now, change differential node refs to a dedicated > message and give them opennet access when someone asks for it, but > implementing that might be harder then if it's got the darknet-only > assumption even more coded in than it was. > > To me, this commit is quite straight-forward, but then again, maybe I > don't see the complexity because I coded it.
The question is does it make the primary use of N2NMs - use by clients over FCP - more difficult? -------------- 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/20080111/1e07d863/attachment.pgp>
