On 12/10/13 23:37, xor wrote: > [Thanks for providing feedback!] > > On Saturday, October 12, 2013 03:26:02 PM you wrote: >> p0s's report for last week talks about synchronous FCP calls and IMHO >> goes in completely the wrong direction: >> >> The stuff on synchronous in-fred notifications is hideous and >> non-network-transparent. > What do you mean by "network transparent"? > >> Having said that I haven't read the code, but >> it sounds hideous. You should have some sort of request/response using >> an identifier, like the main fred FCP does. Or a sequence number or >> something. > There are two possible code paths: > (1) Both plugins are running in the same node. > (2) Inter-node synchronous FCP-calls. Both parties are NOT within the same > node. > > I've only implemented (1). I've implemented it by running a second thread to > execute the FCP call at the target AND having the original calling thread > wait > for it to finish. > > (2) should be implemented like you suggested above. No, they should BOTH wait for a response using the Identifier field. Plugins may well answer asynchronously - "when it returns" is an implementation detail. >> IMHO mechanisms that only work internally should be avoided >> given that everything else we do with FCP is, if not actually >> network-transparent, then could easily be made so. But certainly you >> could provide library code to wait for a single response using a known >> identifier field; ideally the code for using plugins would be network >> transparent via an official java library so it could use the hack you're >> doing if it's internal... in fact, that's wrong: it's a different >> concept. What we should do is wait for a reply to the specific question >> we asked (i.e. wait for a message with the correct label), rather than >> "wait for the function to return" - I mean, what function? Well written >> code only hogs threads when there is a clear benefit in code simplicity. > I suppose your criticism is that the implementation of (1) cannot be > externalized because there is no additional message sent which signals that > the call is finished? 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. >> Feel free to ignore me though, I don't have time to code a proper >> solution. But there was a strong belief at the conference that we should >> try to limit the further accumulation of layers of dirty hacks, and try >> to get rid of some of the existing ones. Especially as the FCP API for >> WoT is necessarily in flux at the moment. > I agree. In fact that is what I was trying to do with implementing > synchronous > FCP calls: There are currently 3 plugins which emulate them, each by having > its own wrapper around PluginTalker (Freetalk, FlogHelper, ContentCuration) > and I've probably forgotten about one. And all of those wrapper- > implementations are buggy IMHO. This signals that there is a need for a > reference implementation. Sure, but it should do it the right way. > The algorithm of event-notifications is mostly asynchronous but some areas > would be a PITA if I had do do them asynchronously. > And I do think that it is a fundamental property of algorithms that some > algorithms will need synchronous communication while others work better > asynchronously. That's probably why most communication frameworks provide > both > types of communication. "Synchronous communication" does not exist at the FCP level. What does exist is messages - requests and responses. This is a perfectly acceptable means of synchronizing! > So my conclusion is: I vote strongly for making Fred provide ways to do > synchronous FCP calls. I am OK with changing the way I've implemented them > though. It already does. We should be consistent between plugins' usage of FCP and fred's usage of FCP. In the fred client layer case, it is very clear: there is ALWAYS an Identifier field on the reply. Sometimes it's more complex e.g. the global queue etc. But that's how we listen/wait for a response. > Anyway, thanks for still reviewing my work even though you are off to > University :) > > PS: Storing an event-notification takes around 1ms so your fear of things > being > slowed down maybe is not fullfilled :) I'm more concerned about the uglification here.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
