[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. > 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? > 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. 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. 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. 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 :) _______________________________________________ Devl mailing list [email protected] https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
