Matthew Toseland wrote:
> 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?
>
I don't believe it does.
