On 24/10/13 05:26, xor wrote: > On Friday, October 18, 2013 04:45:40 PM Matthew Toseland wrote: >> There doesn't need to be. In ALL cases, FCP works like this: >> I send a message with Identifier. >> I get back a message (possibly an error message) with the same Identifier. >> >> At least, that's how node-level FCP works. That's how plugins SHOULD work. > Well where exactly is the "identifier" field you are talking about? > Do you mean the one we pass to PluginRespirator like this: > mConnection = mPluginRespirator.getPluginTalker(mFCPMessageReceiver, > WOT_FCP_NAME, mConnectionIdentifier); I'm not sure whether the code checks that there is a corresponding "Identifier" field, or whether we do some evil hack. I *think* what is happening is that we pass some sort of special value rather than an FCPConnectionHandler? I don't know. Do we or do we not put an Identifier string into the SimpleFieldSet and then look for messages that contain it? > - Thats the client-side code to open a connection to a plugin, i.e. WOT > IMHO this identifier is suitable for being used as a marker for synchronous > calls: > 1) There isn't any checking on the uniqueness of it. They are chosen freely > by > the client. Client authors might use something like their pluginname, which > is > constantly NOT unique. So the "ACK"s would always hit the identifier, no > matter > whether to which sendSynchronous() they belonged. Sure, in which case the client application will break, with or without the synchronous send/wait, unless it uses strictly single threaded communication, because it will have several threads receiving the answers to each other. I.e. not our problem. Identifier identifies a transaction (e.g. a request). > 2) There is nothing which prevents a client from re-using the same > PluginTalker for sending multiple messages to WOT. And it is very likely that > clients will re-use it. For example the reference-client which I wrote does > that and I do think it is the right design. It would be ineffecient to re- > create the whole connection at every send. This makes the identifier not > unique > as well because there will be multiple sends() with the same talker. Arguably > we could mark a talker invalid after a single sendSynchronous() and prevent > future use with that flag. But do we really want people to constantly create > fresh PluginTalker objects using getPluginTalker? "Whole connection" ? I don't even know what you are talking about here: Is this two objects or something substantial? Allocating a single object in Java is really cheap. The first thing you need to do is document how exactly this stuff works. > 3) What WOT specifically needs is to send something *back* at a future point > in > time - event-notifications always happen in the far future. For this, it > keeps > a WeakReference to the "PluginReplySender" of the PluginTalker which was used > to talk to it. I.e. the PluginReplySender allows to send something back to > the > plugin which originally sent something to WOT with the associated > PluginTalker. This is another usecase of continuing to use the same > PluginTalker. Right, and internally we identify that PluginTalker by looking for the unique Identifier, don't we? (Unique within that connection i.e. that plugin???) > Therefore I would rather impement sendSynchronous() to be network transparent > by encapsulating a special random value in the SimpleFieldSet which > identifies > the particular call. Grotesque, pointless, stupid, evil duplication. It works fine in the client layer with just Identifier.
Or maybe it isn't. Maybe there's something I'm not grokking here. We simply don't know because neither of us has any idea how this is actually implemented.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
