This is continued progress toward 1468. It fixes race conditions in SplitFileInserterStorageTest and some problems with the queue getting stuck. It also includes a new and still unstable API (pending feedback) for synchronous bidirectional FCP and inter-plugin communication. See PluginRespirator.connectToOtherPlugin() and FredPluginFCPMessageHandler for details.
When the Library plugin is not loaded the search box on the bookmark
page is now hidden instead of suggesting it be loaded. This is due to
the lack of active search indexes, which made searching slow,
unreliable, and not give useful results.
This does not include plugin updates for purge-db4o compatibility.
Though all but ThawIndexBrowser now compile they have not been tested,
and including them would have added many more hours to the time taken to
make this release.
To use this prerelease either shut down your node and replace
freenet.jar (or whatever is in wrapper.conf classpath), or run
update.(sh|cmd) testing
to download it over clearnet.
CHK@33gMN6FzVGfb13yUSVYmSbLWEDmF-Cr9Xv8ReceWpo0,UruBYAZ1WjtkF~TEG6mR~7jwG17nIJcXqyZoDOiBMEM,AAMC--8/freenet-testing-build-1468-pre2-snapshot.jar
CHK@I63iVCniN7lrSorxxBovziQITmPrYsofEN~2eoDNaUA,k9HtXgGe9Ps-jMadHffgA42t1OU7tFJA0fKiIaHPSH8,AAMC--8/freenet-testing-build-1468-pre2-source.tar.bz2.sig
CHK@daUKvgDMkplSO8s2Ma8cpCBb9Ozv1LK9dmqZkOoIqCw,i3jF4yr~KRvdRRDkG0i9Ok12y~fCJXB5dwLG1sOWyrY,AAMC--8/freenet-testing-build-1468-pre2-source.tar.bz2
CHK@I63iVCniN7lrSorxxBovziQITmPrYsofEN~2eoDNaUA,k9HtXgGe9Ps-jMadHffgA42t1OU7tFJA0fKiIaHPSH8,AAMC--8/freenet-testing-build-1468-pre2-source.tar.bz2.sig
Additional information on build 1468 can be found in the previous
progress report: https://freenetproject.org/news.html#20150315-1468-progress
Changes since build1468-pre1:
---
Bert Massop (1):
PluginInfoWrapper: Add code quality TODO of reducing useless caching
Matthew Toseland (19):
Fix classpath for Eclipse
Don't start() on encoding finished if only getting CHK
Fix bogus ERROR on GetCHKOnly
Fix getWakeupTime() to return -1 when done as contracted.
Move getWakeupTime into Storage (encapsulation, locking!)
Clarify: Javadocs, code style, comments.
Wait at the right point.
Fix barrier code, hence fix race condition in test.
Set max threads to 1, explain why.
Fix another leak
Fix issues with comments
Add FIXME's
Style fixes
Unregister Sender when finishing insert (off thread).
Javadocs
Make storage and sender volatile.
Spacing
Don't need test for null here.
Fix another unit test race condition.
RdrOfTheSt0rm (2):
JavaDoc: fix broken links
JavaDoc: fix more broken links
Steve Dougherty (4):
Reduce startup page refresh period to 1 second
ClientRequester: clarify default behavior
l10n: clarify Norwegian dialect
Fix whitespace
TheSeeker (1):
Remove redundant function
drak@kaverne (12):
Fix whitespace
Add getMimeType() to ManifestElement
ContainerInserter: Use getMimeType, not *Override
Share stuff: Add checkbox to select all Friends.
move checkAll javascript into staticfiles/js/.
hide the no-library warning.
FetchKeyLabel shows that in can download files.
Refactor search box logic into function
remove old unneeded comment
simpler boolean functions
formatting (space after if).
formatting: remove duplicate spaces
saces (1):
eclipse: export freenet-ext.jar
xor-freenet (566):
FCPConnectionHandler: Prepare to use UUID instead of 16
hex-encoded bytes. - UUIDs are 16 bytes as well, so its a perfect
replacement
Start rewrite of FCP plugin communication: - Deprecate
PluginTalker - Add draft of class FCPPluginClient to replace it
- Further implementation will follow on this branch rewrite-plugin-fcp-stuff
FCPPluginClient: Explain why there can only be only be one per
pluginName per FCPConnectionHandler
FCPConnectionHandler: Implement storage of FCPPluginClient objects
FCPConnectionHandler: Improve JavaDoc of double-checked locking
mechanism
FCPClient: Add skeleton of send functions so I can reference them
in JavaDoc - Because sendSynchronous() will wait for the call to
complete at the server, it will also be able to tell whether it
succeeded or failed. Thus it should either return a value, which might
be a boolean or a SimpleFieldSet with information about the error, or
throw an Exception. I decided against passing values because then it
would be asymmetric to what is passed in the initial send: Sending can
pass a SimpleFieldSet AND a Bucket, receiving the result would only be a
SimpleFieldSet OR a Bucket. So we would have to introduce a container
for SimpleFieldSet and Bucket to fix that asymmetry. Also, the return
value should not be abused for passing heavy amounts of data - sync
calls should stay fast to prevent thread pileup. So we better not allow
passing any information besides success/failure.
FCPPluginClient: Add missing imports
FCPPluginClient: JavaDoc code path of sending FCP plugin messages
- It took me some time to figure out how the FCP stuff works, so it
is a good idea to write it down so its easier to read it up in the
future. - The code path is not fully implemented yet, this
documentation also serves as a draft for how it will be implemented.
FCPPluginClient: Make final
FCPPluginClient: Add parameter to send functions which specifies
the direction of the send (client to server or vice versa) - The
other way of implementing this would be to have the send functions of
FCPClient be always client-to server and to have a separate class
"FCPClientReplySender" which contains send functions for sending from
server to client. - Howver the sendSynchronous() will likely be
complex and look the same for client and server, so it doesn't make
sense to have two classes - To implement sendSynchronous() cleanly,
it will act like a normal send() and have the receiver send back an ACK
with another regular send() call. The sendSynchronous() will have to
intercept that ACK and swallow it. By having all messages flow through a
single class - FCPClient - this can be easily achieved. - Also, a
client is a single entity, so it does make sense to represent it as a
single object. - Still, I acknowledge that it is a bit cumbersome to
have the direction parameter and will keep thinking about an easier way
of implementing this. Maybe I come up with one when implementing the
actual send functions.
Add draft of interface FredPluginFCPServer to replace
FredPluginFCP - Deprecates FredPluginFCP
FredPluginFCPServer: Don't abbreviate parameter name
FredPluginFCPServer: JavaDoc
FredPluginFCPServer: Reorder parameters
FredPluginFCPServer: Pass client message identifier to the message
handler - A huge problem with the old PluginTalker stuff was that
the FCP "Identifier" field was not properly declared to be a per-message
identifier. So some clients kept it the same for the whole connection.
And given that it wasn't even passed to the message handler, it was
probably a misconception at design to have it a per-connection
identifier. That rendered it pretty useless: It was being specified by
the client, so there was no guarantee of it being unique to that
particular client connection. Thus it couldn't used for server-side
queries of type "get the client connection for identifier X". By
changing it to be a *message*-identifier in the rewrite, we limit the
scope of the client not chosing it uniquely to the connection of a
certain client. Thus it doesn't matter if its not unique per message:
The client will only disturb its own connection then, not the connection
of others. So it can be safely used for server-side stuff as well. That
applies to the new synchronousSend() particularly: We can use the
messageIdentifier for sending ACK messages to indicate that processing
of the handler at client side completed so synchronousSend() can return.
Add draft of interface FredPluginFCPClient to replace
FredPluginTalker: - Deprecates FredPluginTalker
FredPluginFCPServer: JavaDoc
Deprecate PluginManer.getPluginInfo: It doesn't do what its
JavaDoc says - It will not only return plugins with a matching class
name but also with a matching filename - I should have reviewed the
callers for whether they need the filename matching and removed the
functionality completely if they don't. But the tight WOT release
schedule forbids me from spending too much time on this. So insteadd
this commit just deprecates the function. - Add replacement
functions for querying by class name and by filename. Do not add one for
querying by both - I doubt that this is needed. If someone needs it, it
will be easy to add.
PluginInfoWrapper: Support new interface FredPluginFCPServer -
Deprecate code related to the old interface FredPluginFCP
PluginManager: Add function for getting FCP server plugins with
the new interface FredPluginFCPServer - Deprecates the old
getFCPPlugin() - Will be used by FCPPluginClient - Throw instead
of returning null since the case of not finding a requested plugin is
not normal mode of operation and will not happen with high frequency.
FCPPluginClient: Provide storage for a WeakReference to the
plugin's FCP server - Will be used to implement the actual send
functions.
FCPConnectionHandler.getPluginClient(): Pass the plugin to
FCPPluginClient constructor - The previous commit changed the
constructor to demand it - FCPPluginMessage will use this function.
It shouldn't deal with the low level code of obtaining the plugin so
this is the right place to do this. Also, FCPPluginClient object will be
persisted across the processing of multiple FCPPluginMessages, so
FCPPluginMessage shouldn't query the plugin each time. The fact that the
FCPPluginClient stores it as a WeakReference internally guarantees that
we don't force-keep it in memory. Also, its send-functions will check
whether the reference is valid, so FCPPluginMessage will be able to
indicate failure if the plugin has been unloaded meanwhile
FCPConnectionHandler.getPluginClient(): Improve variable naming
FCPPluginMessage: Remove useless local variable
FCPPluginMessage: Wire-in processing of messages with the new
FCPPluginClient code - Keeps plugins which implement the old
interface working!
FCPPluginClient: Improve JavaDoc
FCPPluginMessage: Fix it to pass through the message identifier
specified by the client. - This adds functions to FCPPluginClient
which allow specification of an identifier. - The functions which do
not allow specification of an indentifier are kept and changed to use a
random UUID as identifier. - JavaDoc is changed to encourage usage
of random identifiers.
FCPPluginClient: Fix constructor for intra-node connections to
take a reference to the client. - If the client is running within
the same node, and thus the FCPConnectionHandler is null, we need to
keep a reference to the client's message handler so we can actually talk
to it. - Also improve the JavaDoc of both constructors: *
Clarify what the situation is with networked and non-networked FCP.
* Don't talk about the FCPConnectionHandler in the constructor which
doesn't take one. Talking about it makes sense only if you read the
JavaDoc of the other constructor before, which is not necessarily always
the case. * Don't refer to networked FCP as "regular" case and
non-networked as "special" case. Both are equally valid uses.
PluginRespirator: Add client-side API connectToOtherPlugin() for
connecting to a plugin with the new plugin FCP stuff. - Deprecate
function getPluginTalker() because the new API was designed to replace
that. - The name was chosen to be "connect*()" instead of "get*()"
because connecting is a more generic and widely used term for
communication between software. - The name was chosen to be
"connectToOtherPlugin()" instead of "connectToPlugin()" due to semantics
of the containing class: PluginRespirator is an object which is handed
to a plugin which is loaded into the node to keep the plugin supplied
with all stuff it needs. So connectToPlugin() would sound like the
plugin which owns the respirator is connecting to itself. - The
function FCPServer.registerFCPPluginClient() which it will need is not
present yet, so compiling will fail. Add a TODO of implementing it
nervertheless to describe what it should do. - The new unrelated
imports are because someone forgot to organize the imports when adding
JavaDoc to other functions.
FCPConnectionHandler / FCPPluginClient: Move construction code to
factory function - IMHO the getPluginManager.getPluginFCPServer()
code is better placed in FCPPluginClient. It's nice to have all code
related to plugin stuff there, makes it more self-contained.
FCPPluginClient: JavaDoc
FCPPluginClient: JavaDoc
FCPPluginClient: Re-order constructor parameters: - First
server, then client. I prefer to order things by semantic hierarchy, and
the server is IMHO higher in that hierarchy.
PluginRespirator / FCPPluginClient: Move construction code to
factory function - IMHO the getPluginManager.getPluginFCPServer()
code is better placed in FCPPluginClient. It's nice to have all code
related to FCP server/client stuff there, makes it more self-contained.
- It doesn't make sense to move the registration code to the
construction function because IMHO freshly constructed objects should be
safe to be thrown away afterwards. This is good because we might
temporarily create objects which are thrown away for threading reasons
as seen in FCPConnectionHandler.getPluginClient()
FCPPluginClient: Rename parameters of public constructors to
follow client/server model - Makes them easier to understand without
having read the whole class
FCPPluginClient: Rename parameters of public constructors to
follow client/server model - Makes them easier to understand without
having read the whole class
FCPPluginClient: Rename stuff to follow client/server model -
Makes it easier to understand
FCPConnectionHandler: Fix JavaDoc
FCPConnectionHandler: Rename stuff to follow client/server model
- Makes it easier to understand
PluginRespirator: Update FIXME with some ideas
PluginRespirator: Update FIXME with some concerns
PluginRespirator: Compile fix
FCPPluginClient: Add / sort asserts
Add JavaDoc draft of class FCPPluginClientTracker: - I
originally planned to have its code in FCPServer because that should be
the interface class for obtaining clients. But that class is large
enough already. Nevertheless, FCPServer can still store the object of
class FCPPluginClientTracker and provide interface functions. This
commit contains a FIXME which states that.
FCPPluginClientTracker: Decide about backend data structure -
I would have prefered a O(1) structure which concurrent, unsynchronized
get() (namely ConcurrentHashMap) instead of the O(n) get() TreeMap, but
unfortunately Java does not offer auto-shrinking HashMaps. In theory I
could have auto-replaced the HashMap with a fresh one if the load factor
has shrunk too much, but that would have required synchronization. Also,
it would be some work to implement, with little benefit: Currently, FCP
is typically exposed to maybe 10 clients at once, so the speed
difference would be not worth the effort.
FCPPluginClientTracker: Implement registerClient() and getClient()
- Inspired by the WOT class ClientTrackerDaemon:
https://github.com/freenet/plugin-WebOfTrust/blob/e5e9d1df3e62a92964807dafe13cecc0749078e7/src/plugins/WebOfTrust/ui/fcp/FCPInterface.java#L116
FCPPluginClientTracker: Implement thread to garbage-colllect
disconnected clients from the TreeMap - This implements the case
where a intra-node-FCP client stops using a a FCPPluginClient object and
it gets GCed, thus nulling the WeakReferences in the TreeMap at
FCPPluginClientTracker. - It does not implement the case where a
FCPPluginClient object is referenced by a networked-FCP
FCPConnmectionHandler and the plugin to which it is connected is
unloaded. In the latter case, the WeakReferences in the FCPPluginClient
will be nulled, and those are not yet monitored by the code of this
commit. Thus, update the FIXMEs in FCPPluginClient to do this.
(FCPServer can be removed from the FIXMes as the code which was planned
to be in FCPServer will be all in its own class FCPPluginClientTracker)
FCPPluginClinetTracker: Simplify JavaDoc
FCPPluginClientTracker: JavaDoc thread startup/shutdown at class level
FCPPluginClientTracker: Add FIXME to optimize locking using a
ReadWriteLock
FCPPluginClientTracker: Make class final - I don't plan to
extend it, so we can get rid of the vtables
FCPPluginClientTracker: Fix warning about unused variable -
I've checked Logger.registerClass(), it is fine with only having the
logMINOR field
FCPPluginClientTracker: Resolve FIXME of using ReadWriteLock
FCPServer: Create a FCPPluginClientTracker and add interface
functions for registering and obtaining clients - The interface
functions registerClient() and getClient() are added to the server
instead of handing out the FCPPluginClientTracker because to an external
user of FCPServer, it doesn't matter how it stores the clients. To the
external user, the FCPServer obviously is the instance which should have
functions for registering/getting clients.
PluginRespirator: Clarify JavaDoc about scope of existence of
FCPPluginClient objects
FCPPluginClientTracker: Remove FIXME resolved by previous commit.
PluginRespirator: Use new FCPServer API registerPluginClient() /
getPluginClient() - The "UPDATE" part of the huge removed FIXME is
not fixed yet, it won't work to implement it that way, which was briefly
suspected by that comment already. There are other FIXMEs at the
WeakReference members in FCPPluginClient which will cause this
functionality to be implemented, so we can safely remove the FIXME here.
- The function call to FCPServer.registerFCPPluginClient() which is
replaced by this comment is not actually a replacement: That function
never existed, the call was merely an intentional breakage of
compilation to enforce implementation of that function. - The
JavaDoc of getPluginClientByID() which is added by this commit
references JavaDoc FredPluginFCPServer which does not exist yet. It will
be shipped in the following commit.
FredPluginFCPServer: JavaDoc the message handling function to
point to the new mechanism of PluginRespirator.getPluginClientByID()
which allows the server to query the node for an existing client after
having exited the message handler - This allows us to tighten the
constraints of what the message handler may do: Since the server plugin
can send replies in the future in another thread by querying for the
client by ID, we now forbid the message handling function to execute for
a long time. - Also, we strongly stress in the JavaDoc that the
mechanism of getting a client by ID in the future is not optional by
explaining why referemces to FCPPluginClient objects must not be kept in
memory
FredPluginFCPServer: Add FIXME of moving client permissions to
FCPPluginClient
FCPPluginClient: Add FIXME of renaming PluginNotFoundException so
we can simplify JavaDoc of functions which throw that Exception
FCPPluginClientTracker: Stress that we only use
ReentrantReadWriteLock because it is the only implementation of
ReadWriteLock
FCPConnectionHandler: Register created FCPPluginClient objects at
the FCPServer - To have the call server.registerPluginClient() be
thread-safe, we need to be able to prevent threads from reading from
pluginClientsByServerPluginName before registerPluginClient() is
finished. (The reason is explained in a comment which is added by this
commit). To allow that, this commit replaces the ConcurrentHashMap with
a TreeMap + ReadWriteLock. This also has the bonus that TreeMaps will
only use as much memory as their content is currently taking. The
backing table of HashMaps in Java never shrinks, it only grows. (I had
commited it to be a HashMap previously nevertheless because we are in a
per-connection class so this would be local to a single client) -
Also make member variables private, no reason to have them visible
FCPPluginClient: Sort member variables - First variables which
shouldn't be null, then WeakReferences and stuff which can be null.
- First server stuff, then client stuff
FCPPluginClient: Unify JavaDoc - Yes, it is always null for
intra-node connections
FCPPluginClient: Use same sorting of member variables in
constructors as in class
FCPPluginClient: Don't use a WeakReference to the intra-node
client since it is the only object which will strongly reference this
FCPPluginClient anyway - Remember: For intra-node connections, the
FCPPluginClient object is strongly references by the actual client app
which uses it. No other fred code keeps a strong reference to such
FCPPluginClient objects. So they can in turn strongly reference the
client app because they will be GCed anyway once the client app stops
referencing them.
FCPPluginClient: Change FIXME to not require cleanup of
FCPPluginClientTracker since it only keeps WeakReferences to the
FCPPluginClients anyway - So we just need to ensure that the strong
references to the FCPPluginClient disappear if the server disappears.
Then the FCPPluginClient will be GCed, and thus the WeakReferences will
become null at the FCPPluginClientTracker, and it will purge it from its
cache using its own ReferenceQueue
FCPServer: Move all construction and registration of
FCPPluginClient objects to this class - FCPServer is a nice place to
deal with handing out clients as a server conceptually manages clients
- This allows us to get rid of the mirror of
FCPPluginClientTracker.registerPluginClient() because the server now
does registration on its own - It also allows us to get rid of the
huge comment which explains thread safety at FCPConnectionHandler: Since
the server will only hand out clients by ID, they cannot be obtained
from the server until the function at FCPConnectionHandler has returned
the client, which it won't until it is finished with storing it at its
own table - and then both tables are coherent.
FCPPluginClient: Make constructor interface functions more
symmetric - Take PluginManager as parameter instead of obtaining it
via indirections so the two constructor functions are symmetric -
Also rename parameter pluginManager in the one constructor function to
serverPluginManager for symmetry between the parameters
FCPPluginClient: JavaDoc - Finish and improve class level
JavaDoc of code paths of sending messages - Don't @link to self,
this is confusing.
FCPPluginClient: Downgrade FIXME of memory management using a
ReferenceQueue to TODO - The reasons for this not being urgent are
explained in JavaDoc which is added - Notice: The said opportunistic
cleaning of the FCPConnectionhandler is not implemented yet. But there
is a FIXME there for that, which I will deal with in the next commits.
- Thanks to nextgens for nagging me about this.
FCPConnectionHandler: Resolve FIXME of dealing with nulled
WeakReferences - This is implemented as opportunistic garbage
collection instead of using a reference queue for the reasons explained
in
https://github.com/xor-freenet/fred-staging/commit/882e1a150b785d11a3ca8f35a26aec6d692d6176
- This also adds a comment about the opportunistic part which points
the user to the location of the JavaDoc which is linked above
FCPPluginClient: Add JavaDoc restrictions to ease future
implementations of FCPPluginClient which allow the server plugin to be
in a different node - The reason for this is the way networking
works: We can know for sure if sending a packet failed because for
example the network adapter will tell us if its cable is unplugged. But
we only know whether it has arrived if we got an actual reply.
FCPPluginClientTracker: JavaDoc
FCPPluginClientTracker: Resolve FIXME of JavaDoc'ing the
registration requirements at other classes - Do not document it at
the client-side interface as originally request by the FIXME: That
interface should be clean of internals stuff, it should be easy to
understand by client authors - Instead, document it at the
constructurs of FCPPluginClient. You will have to use the constructors
for sure when creating clients so you'll run into the JavaDoc.
FCPPluginClient: Trim constructor visibility
FCPPluginClientTracker: Trim class visibility
FCPPluginClient: Sort functions - From high level to low
level. This simplifies their understanding if you read the class from
top to bottom.
FCPPluginClient: Add toString() for use when constructing
Exceptions in following send() implementations
FCPPluginClient: Allow send functions to throw IOException and
JavaDoc the cases when they will do that - I think IOException is a
good type because it is used all over java sockets, streams and file IO.
- The reason why also the asynchronous send functions need to be
able to throws is that under certain conditions it will be possible to
detect immediately that the connection is broken and we cannot even
enqueue the message for sending: When we are trying to send to a server
plugin which has been unloaded, it is definitely known by the
WeakReference being null. With it being null, it wouldn't even be
possible to pretend that the connection is alive by shoving it into a
queue and forgetting about it, because there is no queue to put it to.
Add draft of interface FredPluginFCPMessageHandler to replace
badly named and assymetric interfaces FredPluginFCPServer /
FredPluginFCPClient
FCPPluginClient: Amend FIXME of using something else than
PluginNotFoundException - I think IOException is a good type because
it is used all over java sockets, streams and file IO.
FredPluginFCPMessageHandler: Move JavaDoc from old interfaces to
this one
FredPluginFCPMessageHandler: Move JavaDoc from old interfaces to
this one, also improve it
FredPluginFCPMessageHandler: Move function from old interface to
this one
Indent.
FredPluginFCPMessageHandler: Move function from old interface to
this one
Indent.
FredPluginFCPMessageHandler: Move JavaDoc from old interfaces to
this one, also improve it
FCPPluginMessage: Add missing catching of IOException -
According to the JavaDoc contract of send(), this means that the server
plugin has been unloaded. This is the same case as with the old
PluginTalker code below in the FCPPluginMessage code, so we throw the
same exception now.
FCPPluginMessage: Fix comment to match exception type of send()
FCPPluginClient: Compile-fix imports
Delete interface FredPluginFCPServer: - Fix users to use the
replacement ServerSideFCPMessageHandler. Done with Eclipse auto-renaming
and then manually reviewed: In some instances, it made sense to
explicitely reference it as
"FredPluginFCPMessageHandler.ServerSideFCPMessageHandler" instead of
only "ServerSideFCPMessageHandler" because we want plugins to use
interfaces which start with "FredPlugin*". So in the classes relevant to
them, we should stress that by referencing the extended name. -
Removes the FIXME demanding that at FredPluginFCPMessageHandler, also
corrects the FIXME at ClientSideFCPMessageHandler which should have
referenced the FredPluginFCPClient, not *Server
Indent.
Delete interface FredPluginFCPClient: - Fix users to use the
replacement ClientSideFCPMessageHandler. Done with Eclipse auto-renaming
and then manually reviewed: In some instances, it made sense to
explicitely reference it as
"FredPluginFCPMessageHandler.ClientSideFCPMessageHandler" instead of
only "ClientSideFCPMessageHandler" because we want plugins to use
interfaces which start with "FredPlugin*". So in the classes relevant to
them, we should stress that by referencing the extended name. -
Removes the FIXME demanding the renaming+deletion of the old interface
at FredPluginFCPMessageHandler - Indentation/line wrapping will be
in the following commit.
Indent: - Not pure whitespace because it would have introduced
many almost empty lines, so instead simplify the JavaDoc
FredPluginFCPMessageHandler: Add draft of class FCPPluginMessage
to serve as container for FCP messages - The primary goal of this is
to refactor the way reply messages are sent. With the old approach
without this class, the message handling functions were passed a
FCPPluginClient and could call its send() functions to send a reply OR
many replies. With this class, they shall instead return an object of it
as a reply. - I have thought for a rather long time about this, and
it is necessary for making synchronous FCP calls easy: With this class,
we can force the message handling functions to return a reply message.
So the code which deploys the synchronous calls will know exactly what
the reply is, and particularly whether it is a success / failure. This
would not have been possible easily with the old approach of allowing
the message handling function to call send() on the FCPPluginClient:
What is the success/failure of a message handler if it called send()
multiple times? - Nevertheless, of course the message handling
functions will still be shipped a FCPPluginClient as a parameter in case
they need to send more than one reply, and particularly send future replies.
Fix remaining reference to deleted class FredPluginFCPServer:
- Sorry, had forgotten to grep for this. All should be gone now. -
Side note: Yes, it is a bit strange to have two classes
freenet.node.fcp.FCPPluginMessage and
freenet.pluginmanager.FredPluginFCPMessageHandler:FCPPluginMessage
representing the same thing. However conceptually, the requirements of a
class representing it is different from the perspective of the low level
network FCP interface, and from the client/server side message handling
functions. The client/server side handlers need less low level data, and
more verbose JavaDoc, so its good to have a small self-contained version
of the class in ther FredPluginFCPMessageHandler interface.
FredPluginFCPMessageHandler: Resolve FIXME of moving
ClientPermissions enum - The permissions of a client can change at
any point in time if the user reconfigures the permissions levels of IP
address ranges at the node's web interface. Since everything in class
FCPPluginClient is rather constant over the lifetime of a client, it
would not be a good idea to place the permissions there. That could
provoke the error of people not assuming that they can change. So
instead we place them in the container for invididual FCP messages. This
also has the advantage of stressing the existence of the permissions
more: People are bound to read the whole message container class when
writing message handler functions. The FCPPluginClient class is larger
so the probability of someone reading the whole of it is less. - The
signature of the message handler functions at the server and client
interfaces is the same now, so we can resolve the task of adding the
function to the parent interface for symmetry; and also of passing a
FCPPluginMessage object instead of the individual values.
Fix JavaDoc compilation errors: - As opposed to Eclipse, the
JavaDoc compiler does not recognize the member class of the interface
even if it is imported. It has to be prefixed with the interface which
contains it.
Fix JavaDoc compilation errors: - As opposed to Eclipse, the
JavaDoc compiler does not recognize the member class of the interface
even if it is imported. It has to be prefixed with the interface which
contains it.
Fix JavaDoc typos
FredPluginFCPMessageHandler.ServerSideFCPMessageHandler: Rename
function in preparation of adding it to parent interface - It shall
be the same as in ClientSideFCPMessageHandler, so it needs a more
generic name.
FredPluginFCPMessageHandler.ClientSideFCPMessageHandler: Rename
function in preparation of adding it to parent interface - It shall
be the same as in ServerSideFCPMessageHandler, so it needs a more
generic name.
FredPluginFCPMessageHandler: Resolve FIXME of having a common
message handling function for server- and client-side handlers - Do
not delete the child interfaces
ServerSideMessageHandler/ClientSideMessageHandler as their primary
purpose is to explain the different constraints on the message handling
function in their JavaDoc
FredPluginFCPMessageHandler: Use the new container class
FCPPluginMessage to encapsulate the parameters passed to message
handling functions; Update JavaDoc - The fact that we now make
message handlers return the reply message instead of sending them on
their own using the send() functions of the FCPPluginClient at first
seems like a unnecessary restriction. However it is not: It allows us to
unify the format of success/failure messages. They will always be
indicated by the Boolean success in the FCPPluginMessage, so their
on-network format can always look the same. Previously, stuff like WOT
had many different values in the SimpleFieldSet such as
"IdentityCreated", "TrustSet" etc for indicating the success of an
operation. Now success/failure messages will all look the same. This in
turn allows the synchronous send functions to monitor the network data
for those messages to allow the synchronous and thereby blocking
operation to return. Notably, the on-network format can stay as is :)
- In addition to using the new FCPPluginMessage, the JavaDoc of
various stuff in FredPluginFCPMessageHandler is also clarified. - I
used the Eclipse feature for changing function signatures, so other
classes which reference this are also changed. The indentation / line
length will be fixed in the following commit.
Indent / Tweak JavaDoc: - Always reference the
FredPluginFCPMessage.FCPPluginMessage with the interface which contains
it as prefix to distinguish from the freenet.node.fcp.FCPPluginMessage.
I might still rename it, but not yet.
FCPPluginClient / FredPluginFCPMessageHandler: Add function to
compute ClientPermissions; document ClientPermissions - The function
will be used by the FCPPluginClient.send() implementations
FredPluginFCPMessageHandler: JavaDoc
FredPluginFCPMessageHandler.FCPPluginMessage.identifier: Simplify
and clarify JavaDoc - Don't mention the fact that server's send
messages on their own as this doesn't really fit here and we already
have it as class-level JavaDoc of FredPluginFCPMessageHandler now
FredPluginFCPMessageHandler.FCPPluginMessage: Allow the class to
be used for outgoing messages as well so we have more symmetry
FredPluginFCPMessageHandler.FCPPluginMessage: Allow client
permissions to be null for outgoing messages - Doesn't make any
sense to specify permissions when sending something
FredPluginFCPMessageHandler.FCPPluginMessage: Simplify JavaDoc
FredPluginFCPMessageHandler.FCPPluginMessage: Add asserts() to
constructor
FredPluginFCPMessageHandler.FCPPluginMessage: Add constructors for
outgoing messages; Encapsulate in factory functions - This will
allow server and client to construct outgoing messages to pass them to
the FCPPluginClient send() functions. (Following commits will adapt the
send functions) - Also greatly improves the JavaDoc
FredPluginFCPMessageHandler: Adapt JavaDoc of interfaces for
server/client message handler to benefit of the recent improvement of
FCPPluginMessage constructors
FCPPluginClient: Get rid of wrapper send() functions for using
random message identifiers - The following commit shall convert the
primary send functions to eat FCPPluginMessage objects instead of
manually taking all their data as parameters. Thus, the message
identifiers will be encapsulated. The different constructors of the
FCPPluginMessage now do the job of deciding whether to use a random
message identifier or now.
Remove trailing whitespace.
Fix line length and indentation to follow coding standards. Sorry.
- For each modified file, only fix the lines which my branch has
already touched. Preexisting lines are not fixed to prevent merge-hell
when merging toad's db4o removal branch: He also did work on FCP. This
is also coherent with what we have discussed for changing indentation
from tabs to spaces: We want to do it opportunistically for stuff as it
is modified, not for all files / lines at ones.
Remove trailing whitespace.
Fix line length and indentation to follow coding standards. Sorry.
- Lines whose length is not fixed are subject to be removed anyway
when this branch is finished.
Remove trailing whitespace.
Add missing @Override annotation
Fix line length and indentation to follow coding standards. Sorry.
Fix line length and indentation to follow coding standards. Sorry.
- For each modified file, only fix the lines which my branch has
already touched. Preexisting lines are not fixed to prevent merge-hell
when merging toad's db4o removal branch: He also did work on FCP. This
is also coherent with what we have discussed for changing indentation
from tabs to spaces: We want to do it opportunistically for stuff as it
is modified, not for all files / lines at ones.
Fix line length and indentation to follow coding standards. Sorry.
- For each modified file, only fix the lines which my branch has
already touched. Preexisting lines are not fixed to prevent merge-hell
when merging toad's db4o removal branch: He also did work on FCP. This
is also coherent with what we have discussed for changing indentation
from tabs to spaces: We want to do it opportunistically for stuff as it
is modified, not for all files / lines at ones.
Remove trailling whitespace
Fix line length and indentation to follow coding standards. Sorry.
Fix line length and indentation to follow coding standards. Sorry.
- For each modified file, only fix the lines which my branch has
already touched. Preexisting lines are not fixed to prevent merge-hell
when merging toad's db4o removal branch: He also did work on FCP. This
is also coherent with what we have discussed for changing indentation
from tabs to spaces: We want to do it opportunistically for stuff as it
is modified, not for all files / lines at ones.
Fix line length and indentation to follow coding standards. Sorry.
- For each modified file, only fix the lines which my branch has
already touched. Preexisting lines are not fixed to prevent merge-hell
when merging toad's db4o removal branch: He also did work on FCP. This
is also coherent with what we have discussed for changing indentation
from tabs to spaces: We want to do it opportunistically for stuff as it
is modified, not for all files / lines at ones.
Fix line length and indentation to follow coding standards. Sorry.
- For each modified file, only fix the lines which my branch has
already touched. Preexisting lines are not fixed to prevent merge-hell
when merging toad's db4o removal branch: He also did work on FCP. This
is also coherent with what we have discussed for changing indentation
from tabs to spaces: We want to do it opportunistically for stuff as it
is modified, not for all files / lines at ones.
FredPluginFCPMessageHandler: Fix JavaDoc typo
FredPluginFCPMessageHandler: Improve JavaDoc choice of words
PluginRespirator: Fix JavaDoc typo
Fix if()s to follow newly enforced code style conventions. Sorry.
FredPluginFCPMessageHandler.FCPPluginMessage: JavaDoc the purpose
of the message identifier.
freenet.node.fcp.FCPPluginMessage: Parse "Success" field in plugin
messages - This is mainly needed for the planned synchronous send()
functions in FCPPluginClient. Because synchronous operations are
blocking, we need the remote partner to tell us when the send() function
can stop blocking and return. Thus, we need to send a reply message to
every (non-reply) message to indicate that the call is finished. To
indicate that the message is a reply, the "Success" field is used. -
Bonus feature: Because we'll be sending replies anyway, we can also ship
the information of whether the operation succeeded or not - so the
success field is boolean. It will probably also be useful to allow
shipping of an error code and error message, the following commit will
add a FIXME for that. - Bonus feature: The whole of this makes the
stuff more similar to standard "remote procedure call" operations. Each
non-reply message is a procedure call, each reply is the procedure
result, and they only happen in pairs. - This new FCP field is not
yet added to the official documentation of FCP (= the freenet Wiki). I
will do that as soon as the code is merged into mainline.
freenet.node.fcp.FCPPluginMessage: Add FIXME of adding ErrorCode /
ErrorMessage fields since we ship the Success field already
FCPPluginClient: Increase visibility of computePermissions() -
Will be needed by outside functions who want to construct
FredPluginFCPMessageHandler.FCPPluginMessage objects, the constructor
needs the permissions.
FCPPluginClient.send(): Change it to eat FCPPluginMessage objects
instead of manually taking all their data as parameters. - Was done
using Eclipse refactoring tools, so the callers and JavaDoc is adapted
as well.
FCPPluginClient: Link to JavaDoc of FredPluginFCPMessageHandler as
it provides a nice overview of how plugin FCP works from the server /
client implementation perspective
FCPPluginClient: Make send functions public - They are to be
used in server and client plugins, which will be in a different package.
FCPPluginClient.SendDirection: Remove overkill JavaDoc - The
referenced functions are directly below, and even with bare HTML JavaDoc
it would be obvious for what this is used.
FCPPluginClient.sendSynchronous(): Change it to eat
FCPPluginMessage objects instead of manually taking all their data as
parameters. Also return one - This function will be a blocking call
which waits for the remote side to reply that the operation completed.
Thus, as the reply is available during execution of the function, it can
return it.
FCPPluginMessage: Add FIXME to have a separate field in messages
which makes it very clear that they are a reply - The distinction
between non-reply and reply messages is very important for the new API
because FCPPluginClient.sendSynchronous() *needs* a reply so it can
determine when to return. So it should be ensured that custom client
implementations don't break detection of reply messages. This would be
very likely if we only used "Success" as an implicity indicator of replies.
FCPPluginClient: Require an Executor in public factory functions
- Will be needed for the asynchronous send functions to generate
threads to deploy the messages in case of intra-node FCP - The
following commits will pass it down to the constructors and store it.
FCPPluginClient: Require an Executor in constructors, pass it down
from factories - Will be needed for the asynchronous send functions
to generate threads to deploy the messages in case of intra-node FCP
- The following commits will store it
FCPPluginClient: Store executor which the constructors already
receive - Why we need it is documented in the JavaDoc of the member
variable
FCPPluginClient: Add missing assert(executor != null) to
constructors/factories
FCPPluginClient.SendDirection: Add invert() function - This
can be used in the following implementation of the send functions when
sending back the reply. Then the path for sending the reply will be the
same no matter what the original send direction was.
FCPPluginClient: Add toStringShort() - Will be used for thread
names. Those must be shorter than what toString() returns currently to
fit into the thread table at FProxy's statistics page
FCPPluginClient.SendDirection.inverse(): Rename to invert() -
This was originally planned to be the name. Sorry
FCPPluginClient: Finally implement send() :) - It is a huge
nerdgasm to see that it wound up to be this symmetric :) I hope this
helps to justify why I rewrote the plugin FCP stuff... - The
incomplete parts are marked with UnsupportedOperationException throwing
FIXME. They should be finished before this gets merged.
FCPPluginClient.send(): Add FIXME of simplifying the function layout
FredPluginFCPMessageHandler: Clarify JavaDoc
FredPluginFCPMessageHandler: Allow specification of thread
priority for message handling functions
FredPluginFCPMessageHandler: Fix JavaDoc links to old API -
The PluginTalker was the class which was used to send messages - The
PluginReplySender was the class which was used to send replies - The
FredPluginFCP was the message handler interface which received the
messages - The FredPluginTalker was the message handler interface
which received the replies.
FredPluginFCPMessageHandler: Improve JavaDoc which describes the
difference to the old API
FCPPluginClient.send(): Use thread priority which is specified by
the message handler - The fact that PrioRunnable returns an integer
sucks, and a bug to fix this has been filed at
https://bugs.freenetproject.org/view.php?id=6312
FCPPluginClient.send(): Resolve FIXME of re-ordering if()s to be
more flat / simple
FCPPluginMessage & FCPPluginReply: JavaDoc their purpose as
compared to each other and other representations of messages
FCPPluginReply: Allow construction of replies which contain a
"Success" field - This serves as the inverse of the "Success"
field which we parse in freenet.node.fcp.FCPPluginMessage. - It will
be used by FCPPluginClient.send() to produce server-to-client messages.
- The FIXMEs at the "success" variable of FCPPluginMessage apply, so
this commit adds mentioning of FCPPluginReply there.
FCPPluginClient.send(): Implement sending messages over network
- This is done the same way the old class PluginReplySenderFCP did it.
FCPPluginClient.send(): Resolve FIXME of dealing with IOException
when sending the reply.
Trim trailling whitespace
Add some whitespace for readability
FredPluginFCPMessageHandler: Document the fact that message
handlers should not throw
FCPPluginReply: Add asserts() to constructor to specify
requirements of the parameters - Use assert instead of throwing so
the deprecated constructor which uses this one does not break outside of
development environments. Also, this function will be used a lot, so it
would suck to have null-checks execute always. - The SFS can be
null: getFieldSet() uses SimpleFieldSet.put(String, SimpleFieldSet) to
add it to another SimpleFieldset, and that put() allows it to be null.
FredPluginFCPMessageHandler.FCPPluginMessage: Update constructor
requirements to match FCPPluginReply constructor - Also add
asserts() to check them.
FCPPluginClient: Use the fact that the SimpleFieldSet of messages
is allowed to be null now
FCPPluginClient.send(): Resolve FIXME of handling exceptions
thrown by message handlers
FCPPluginClient.send(): Resolve FIXME of handling replies to
replies as an error
FCPPluginClient.send(): Improve and unify logging
FredPluginFCPMessageHandler.FCPPluginMessage: Add errorCode and
errorMessage fields - The fact that we standardized signaling of
errors with the "success" field suggests that we also standardize
transportation of error codes. - The following commits will make the
constructors accept the new fields.
FredPluginFCPMessageHandler.FCPPluginMessage: Consume errorCode /
errorMessage in constructor - The following commit will make the
factory functions require it as well
FredPluginFCPMessageHandler.FCPPluginMessage.construct(): Pass
null for errorCode / errorMessage to constructor - This factory
function is only for non-reply messages as specified by its JavaDoc, so
errorCode / errorMessage must be null.
FredPluginFCPMessageHandler.FCPPluginMessage.constructReplyMessage():
Consume errorCode / errorMessage and pass it down to the constructors
- This already fixes JavaDoc references to use the new syntax. Caller
code will be fixed in the following commit.
FredPluginFCPMessageHandler.FCPPluginMessage: Specify which
errorCode and errorMessage shall be used for unknown errors such as
unexpected Exceptions - Will be used by the following commit which
is to continue to adapt callers of the factory functions to their new
signature
FCPPluginClient: Adapt callers of
FCPPluginMessage.constructReplyMessage() to new signature - Pass
through the Exception.toString() as suggested by JavaDoc of errorMessage
in terms of unexpected errors: It will contain the class name of the
Exception, and a localized error description, or a non-localized one if
there is no translation.
FredPluginFCPMessageHandler.FCPPluginMessage: JavaDoc
FredPluginFCPMessageHandler.FCPPluginMessage.constructRawMessage():
Require errorCode & errorMessage; Adapt callers to new signature -
This effectively adds "ErrorCode" and "ErrorMessage" fields to the
on-network format. They are not documented in the FCP Wiki yet. Will do
this once the branch gets merged - This only adapts the network
format parser class fcp.FCPPluginMessage. What remains is to change the
serializer class FCPPluginReply to also put them into the network message.
FCPPluginReply: JavaDoc code quality improvement which can be done
upon removal of deprecated code
FCPPluginReply: Consume & serialize the new
FCPPluginMessage.errorCode and errorMessage fields; Improve constructor
layout - We remove the assert()s and instead consume a
FCPPluginMessage to ensure that the assert()s of FCPPluginMessage get
executed instead. This causes the legacy constructor to be exactly the
same as the one before the new plugin FCP API was implemented. This will
keep the legacy stuff working the same way for nodes which have assert()
enabled. We don't enable it by default, but some developers might enable
it for their production nodes. Also, removing the assert()s of course
reduces code duplication as we have the same ones in FCPPluginMessage
already. - This also adapts the callers to use the new constructor
signature
FredPluginFCPMessageHandler.FCPPluginMessage: Improve JavaDoc of
requirements upon errorCode and errorMessage
FCPPluginClient: Begin implementation of sendSynchronous() -
Add backend datastructures and huge JavaDoc which explains how they will
be used by the actual implementation.
FCPPluginClient.sendSynchronous(): Add assert()s to prevent poor
choice of timeout.
FCPPluginClient.sendSynchronous(): Initial implementation
FCPPluginClient.sendSynchronous(): Explain why we assert() instead
of throwing
FCPPluginClient: Fix typo in comments
FCPPluginClient.sendSynchronous(): Return a reply with
success==false instead of throwing
FCPPluginClient.sendSynchronous(): JavaDoc its purpose and rules
FCPPluginClient.sendSynchronous(): Add JavaDoc which stresses that
it should only be used when absolutely necessary
FCPPluginClient.sendSynchronous(): Remove already resolved FIXME
FCPPluginClient.SynchronousSend / sendSynchronous(): JavaDoc
FCPPluginClient: Use Condition.signal() instead of signalAll() for
all synchronous send stuff
FCPPluginClient.sendSynchronous(): Create the Condition where it
is actually used
FCPPluginClient.sendSynchronous(): Rename local variable to match
its class name
FCPPluginClient.sendSynchronous(): Fix wrong documentation
FCPPluginClient.sendSynchronous(): Clarify documentation - The
reply message is received, not the SynchronousSend
FCPPluginClient.sendSynchronous(): Clarify documentation
FCPPluginClient.sendSynchronous(): Improve English
FCPPluginClient.sendSynchronous(): Do not swalow InterruptedException
FCPPluginClient.sendSynchronous(): Indent.
FCPPluginClient.sendSynchronous(): Documentation
FCPPluginClient.sendSynchronous(): Don't reset timeout upon
spurious wakeup of Condition.await()
FCPPluginClient.sendSynchronous(): Fix memory leak
FCPPluginClient.send(): Pass replies to eventually waiting
sendSynchronous() threads
FCPPluginClient.sendSynchronous(): Improve documentation about
proper message identifiers
FCPPluginClient.sendSynchronous(): JavaDoc the parameters
FCPPluginClient.sendSynchronous(): Fix missing reason for
IOException in throws declaration
FCPPluginClient.sendSynchronous(): JavaDoc why it throws
InterruptedException
FCPPluginClient.sendSynchronous(): Link JavaDoc of asynchronous send()
FCPPluginClient.sendSynchronous(): Document to *where* it is sending
FCPPluginClient.sendSynchronous(): Add guaranteed order of message
delivery to advantages
FCPPluginClient.sendSynchronous(): Unify style / language of JavaDoc
FCPPluginClient.send(): JavaDoc the implications of asynchronous
sending
FCPPluginClient.send()/sendSynchronous(): JavaDoc parameter direction
FCPPluginClient.sendSynchronous(): Remove self-explanatory JavaDoc
FCPPluginClient.send(): JavaDoc parameter message
FCPPluginClient.sendSynchronous(): When talking about async
send(), also mention "non-blocking"
FCPPluginClient.send(): Add @see link to sendSynchronous()
The two classes FCPPluginMessage: Add/unify JavaDoc which explains
the differences between them
FCPPluginMessage: Remove already resolved FIXME
FCPPluginMessage: Add FIXME which proposes a solution to the name
clash
FCPPluginReply: Add FIXME to rename it to FCPPluginServerMessage
PluginRespirator.getPluginClientByID() and backend: Throw
IOException instead of PluginNotFoundException
FCPPluginClient.send(): Fix logging of messsages for which the
handler threw
FredPluginFCPMessageHandler: Document how to transport error
descriptions
Rename class FCPPluginReply to FCPPluginServerMessage
Rename class freenet.node.fcp.FCPPluginMessage to
FCPPluginClientMessage
Fix a remaining case of renaming FCPPluginMessage to
FCPPluginClientMessage
FCPPluginClientMessage: Document that the class name differs to
the on-network name
FCPPluginClientMessage: Use constant instead of hardcoding
Reference "FredPluginFCPMessageHandler.FCPPluginMessage" by
"FCPPluginMessage" instead
Reference "FredPluginFCPMessageHandler.FCPPluginMessage" by
"FCPPluginMessage" instead
Organize imports
Reference "FredPluginFCPMessageHandler.FCPPluginMessage" by
"FCPPluginMessage" instead
Reference "FredPluginFCPMessageHandler.FCPPluginMessage" by
"FCPPluginMessage" instead
Reference "FredPluginFCPMessageHandler.FCPPluginMessage" by
"FCPPluginMessage" instead
FCPPluginClient.send(): Split part of the function into
sendNetworked()
FCPPluginClient: Rename sendNetworked() to dispatchMessageByNetwork()
FCPPluginClient: Add draft of function for splitting synchronous
message dispatching code out of send()
FCPPluginClient.send(): Prepare split into dispatchMessageByNetwork()
FCPPluginClient.maybeDispatchMessageLocallyToSendSynchronousThread():
Reduce nesting
Indent.
FCPPluginClient.maybeDispatchMessageLocallyToSendSynchronousThread():
Reduce nesting
FCPPluginClient.maybeDispatchMessageLocallyToSendSynchronousThread():
Finish by adding remaining return statements
Indent.
FCPPluginClient: Remove useless IOException declaration
FCPPluginClient.send(): Add draft of function for splitting it up
even more
FCPPluginClient.send(): Prepare the final splitup
FCPPluginClient.dispatchMessageLocallyToMessageHandler(): Fix
wrong log String
FCPPluginClient.dispatchMessageLocallyToMessageHandler(): Fix
wrong log String
FCPPluginClient.dispatchMessageLocallyToMessageHandler():
Documentation
FCPPluginClient: Fix missing semicolon in logging
FCPPluginClient: Improve logging
FCPPluginClient: Fix documentation referencing a variable which
has been renamed
FCPPluginClient: Remove FIXME of splitting up send()
FCPPluginClient: Add missing <br> to JavaDoc
FCPPluginClient.send():
FCPPluginClient: Fix class level JavaDoc to adapt to recent changes.
FCPPluginClient: Fix class level JavaDoc to adapt to recent changes.
FCPPluginClient: Fix class-level JavaDoc to talk about "UUID"
instead of "ID"
FredPluginFCPMessageHandler: Fix JavaDoc to talk about "UUID"
instead of "ID"
Document the disconnection mechanism of clients towards which
were passed to FredPluginFCPMessageHandler server plugins
FredPluginFCPMessageHandler: Make the JavaDoc flow of thought more
well-connected
FredPluginFCPMessageHandler: Stress that the server shall store
UUIDs, not FCPPluginClient hard references
FCPPluginClient.getID(): Add FIXME about renaming it to getUUID()
FCPPluginClient: Remove FIXME of renaming getID() to getUUID()
FCPPluginClient: Mention synchronous sends in class level JavaDoc
about sending code paths.
FCPPluginClientMessage: Remove FIXME of adding a "IsReply" /
"IsAnswer" field to the on-network format
FCPPluginClientMessage / FCPPluginServerMessage: Move JavaDoc to
FCPPluginMessage
FCPPluginClientMessage / FCPPluginServerMessage: Reduce lines of code
FCPPluginClientMessage / FCPPluginServerMessage: JavaDoc
FCPPluginClientMessage / FCPPluginServerMessage: Downgrade FIXME
of renaming network messages to TODO
FCPPluginClientTracker: Fix thread not looping
Indent.
FCPPluginClient.dispatchMessageLocallyToMessageHandler(): Fix
NullPointerException
FredPluginFCPMessageHandler.FCPPluginMessage: Add FIXME of adding
a reply constructor with less parameters as some of them will
usually be not needed
FredPluginFCPMessageHandler.FCPPluginMessage: Add shortcut
constructors
Update JavaDoc which references
FredPluginFCPMessageHandler.FCPPluginMessage constructors to mention
shortcuts to them
FCPPluginMessage: Rename member "parameters" to "params"
FCPPluginClient.sendSynchronous(): Increase default timeout
assert() limit
FCPPluginMessage JavaDoc: Stress very much that for replys, a
reply constructor must be used.
FCPPluginClient.sendSynchronous() JavaDoc: Stress very much that
the reply can indicate an error even if the function did not throw
FCPPluginClient: Add constructor for unit tests
NodeStarter: Get rid of 24 parameter constructor
FCPPluginClient.constructForUnitTest(): JavaDoc how to create a
non-fake FCPluginClient in unit tests
NodeStarter.TestNodeParameters: Allow enabling the web interface
Revert "NodeStarter.TestNodeParameters: Allow enabling the web
interface"
NodeStarter.TestNodeParameters: Make it clear how the node
directory is specified
NodeStarter.globalTestInit(): Allow specification of a RandomSource
NodeStarter.TestNodeParameters: Fix wrong JavaDoc which I had added
NodeStarter.globalTestInit(): Make parameters more self-explanatory
Node: Fix ClassCastException when using DummyRandomSource instead
of Yarrow
NodeStarter.globalTestInit(): JavaDoc the return value
PluginRespirator.connecToOtherPlugin(): Fix typo in function name
PluginRespirator.connectToOtherPlugin(): JavaDoc how to disconnect
PluginRespirator.connectToOtherPlugin(): Remove brackets of
JavaDoc which people should read
FredPluginFCPMessageHandler...handlePluginFCPMessage(): Document
that people should always return a reply
FCPPluginMessage: Improve toString()
FCPPluginMessage.toString(): Sort the SimpleFieldSet
FCPPluginMessage.toString(): Put SimpleFieldSet into new line
FCPPluginClient: Implement logging of all messages
FredPluginFCPMessageHandler: JavaDoc how to log all messages
FCPPluginServerMessage: Renam constructor parameter
FCPPluginServerMessage: Fix unused constant PARAM_PREFIX and use it
FCPPluginClientMessage: Provide function for constructing a
FCPPluginMessage
FCPPluginMessage: Implement test to check encoding/decoding into
the on-network format
FCPPluginServerMessage: Fix encoding of messages with empty
FCPPluginMessage.params
FCPPluginClientMessage: Prevent NPEs in server code
FCPPluginMessage: Fix bugs and insecurity of "permissions" field
FCPPluginMessageEncodeDecodeTest: Fix wrong order of assert*() params
FCPPluginClient: Fix traffic dump logs not matching actual traffic
FCPPluginClient: Document that order of message logging is not
necessarily order of message delivery
FCPPluginClient: Fix logging of raw traffic to be DEBUG, not MINOR
FCPPluginClient: Log sendSynchronous() calls and the size of their
table
FredPluginFCPMessageHandler: Fix typo in JavaDoc HTML tags
FCPPluginClient.sendSynchronous(): Add assert
PluginManager: Fix NullPointerException
FredPluginFCPMessageHandler.FCPPluginMessage: Fix NPE
FCPPluginMessage.toString(): Fix operator priority issue
FCPPluginClient.sendSynchronous(): Add performance FIXME
FCPPluginClient: Don't fake missing replies, log instead.
FredPluginFCPMessageHandler: Allow chosing thread priority per message
FCPPluginClient: Don't call plugin code without catch(everything)
FCPPluginMessage.toString(): Really fix operator priority issue
FCPPluginClient.sendSynchronous(): Logging
FCPPluginClient: Document how sendSynchronous() shutdown works
Organize imports
FCPPluginClient.sendSynchronous(): Unit-test thread safety
FCPPluginClient: Remove FIXME of testing thread safety
FCPPluginClient.sendSynchronous(): Lower assert() limit for timeout
PluginRespirator.connectToOtherPlugin(): JavaDoc
PluginRespirator.connectToOtherPlugin(): JavaDoc
PluginRespirator.connectToOtherPlugin(): JavaDoc
FCPPluginClient.send(): JavaDoc
PluginRespirator.connectToOtherPlugin(): JavaDoc grammar fix
PluginRespirator.connectToOtherPlugin(): JavaDoc
PluginRespirator.getPluginClientByID(): JavaDoc
PluginRespirator.getPluginClientByID(): Rename
FredPluginFCPMessageHandler: JavaDoc
FredPluginFCPMessageHandler: JavaDoc
FredPluginFCPMessageHandler: JavaDoc
FCPPluginMessage: Assert errorCode to be alpha-numeric
FCPPluginMessage: JavaDoc
FCPPluginMessage.isReplyMessage(): JavaDoc
FCPPluginMessage: JavaDoc
FCPPluginMessage.constructRawMessage(): JavaDoc
FredPluginFCPMessageHandler: JavaDoc
FredPluginFCPMessageHandler: JavaDoc
Organize imports
ServerSideMessageHandler: JavaDoc
ServerSideMessageHandler: JavaDoc
FredPluginFCPMessageHandler.*.handlePluginFCPMessage(): JavaDoc
FredPluginFCPMessageHandler.*.handlePluginFCPMessage(): JavaDoc
ClientSideFCPMessageHandler: JavaDoc
FredPluginFCPMessageHandler.*.handlePluginFCPMessage(): JavaDoc
FredPluginFCPMessageHandler.*.handlePluginFCPMessage(): JavaDoc
PrioritizedMessageHandler: JavaDoc
FCPPluginClient: JavaDoc
FCPPluginClient: JavaDoc
FCPPluginClient: JavaDoc
FCPPluginClient: JavaDoc
FCPPluginClient: JavaDoc
FCPPluginClient: JavaDoc fixes
FCPPluginClient: JavaDoc fixes
FCPPluginClient: Minor JavaDoc tweak
FCPPluginClient: Minor memory usage tweak
FCPPluginClient: JavaDoc readability fixes
FCPPluginClient: JavaDoc grammar fix
FCPPluginClient: Remove obsolete JavaDoc
FCPPluginClient: Remove overly verbose JavaDoc
FCPPluginClient.send(): JavaDoc fixes
FCPPluginClient: Fix English word mixup
FCPPluginClient: JavaDoc fixes
FCPPluginClient: Add code quality TODO
FCPPluginClient: JavaDoc fixes
FCPPluginClient: JavaDoc fixes
FCPPluginClient: JavaDoc fixes
FCPPluginClient: JavaDoc tweak
FCPPluginClient: JavaDoc fixes
FCPPluginMessageEncodeDecodeTest: Fix failure
FCPPluginClientTracker: JavaDoc fixes
PluginRespirator.connectToOtherPlugin(): JavaDoc fixes
Post-merge fixes of merging purge-db4o
Post-merge fixes of merging purge-db4o
Post-merge fixes of merging purge-db4o
Post-merge fixes of merging purge-db4o
Post-merge fixes of merging purge-db4o
Post-merge fixes of merging purge-db4o
Post-merge fixes of merging purge-db4o
Post-merge fixes of merging purge-db4o
Post-merge fixes of merging purge-db4o
Post-merge fixes of merging purge-db4o into plugin-fcp-rewrite
Finish post-merge fixes of merging purge-db4o into plugin-fcp-rewrite
Deprecate classes PluginReplySender*
FCPServer.createClientForNetworkedFCP(): Rename
FCPServer.createPluginClientForIntraNodeFCP(): Rename
FCPPluginClient: Fix post-purge-db4o-merge glitch
FCPPluginClient.sendSynchronous(): JavaDoc timeout limits
FCPPluginClient.send(): Improve readability
FCPConnectionHandler: Add send() to replace public member variable
usage
FCPPluginClient: Don't use FCPConnectionHandler member variable
FCPPluginClient.toStringShort(): Move to better place
FCPServer.createFCPPluginClient*(): Trim / document visibility
PluginManager.getFCPPlugin(): Explain deprecation
PluginManager.getFCPPlugin(): Fix deprecation JavaDoc
PluginManager.getFCPPlugin(): Explain how to finish the deprecation
PluginManager.getPluginFCPServer(): Move internals to
PluginInfoWrapper
FCPPluginClient.computePermissions(): Rename to
getCurrentPermissions()
FredPluginFCPMessageHandler.FCPPluginMessage: Move to own file
FCPPluginMessage: Move to package freenet.clients.fcp
FCPPluginMessage.constructRawMessage(): Trim visibility
FCPPluginClient.isDead(): Rename to isServerDead()
FCPPluginClient.isServerDead(): Trim visibility
FCPPluginClient.getServerPluginName(): Trim visibility
FCPPluginClient: Extract interface FCPPluginConnection
Organize imports
FCPPluginConnection: Clarify that server is a plugin, client may
not be
FCPPluginConnection: Adapt JavaDoc to rename "Client" -> "Connection"
FCPPluginConnection: Move "Internals" javadoc back to FCPPluginClient
FCPPluginConnection: Add missing license header
FCPPluginConnection: Adapt JavaDoc to rename "Client" -> "Connection"
FCPPluginConnection.getID(): Adapt to rename "Client" -> "Connection"
FCPPluginConnection.send(): Fix "synchronousSend()" function name
mixup
FCPPluginConnection.send(): Adapt to rename "Client" -> "Connection"
Indent.
FCPPluginConnection.sendConnection: Fix incoherent JavaDoc
FCPPluginConnection.sendSynchronous(): Adapt to Client/Connection
rename
Indent.
FCPPluginClient.SendDirection: Move to FCPPluginConnection
FCPPluginConnection: Add getServerPluginName()
FCPPluginConnection.getServerPluginName(): JavaDoc from user's view
FCPPluginConnection.getServerPluginName(): Fix useless line wrap
FCPluginClientMessage: Adapt to rename "Client" -> "Connection"
FCPluginServerMessage: Adapt to rename "Client" -> "Connection"
FCPPluginClientTest: Fix for moved enum SendDirection
FCPPluginMessage: Linkify class names in JavaDoc
FCPPluginMessage: Add line breaks to JavaDoc
FCPPluginMessage: Adapt to rename "Client" -> "Connection"
Indent.
FredPluginFCPMessageHandler: Fix too lax JavaDoc
FredPluginFCPMessageHandler: JavaDoc how to implement a server /
client
FredPluginFCPMessageHandler: Adapt to Client/Connection rename
FredPluginFCPMessageHandler: Remove redundant JavaDoc
FredPluginFCPMessageHandler: Adapt to Client/Connection rename
FredPluginFCPMessageHandler: Adapt to Client/Connection rename
FredPluginFCPMessageHandler: Adapt to Client/Connection rename
FredPluginFCPMessageHandler: Adapt to Client/Connection rename
PluginInfoWrapper: Organize imports
PluginReplySender: Adapt to rename "Client" -> "Connection"
PluginReplySenderDirect: Adapt to rename "Client" -> "Connection"
PluginReplySenderFCP: Adapt to rename "Client" -> "Connection"
PluginTalker: Adapt to rename "Client" -> "Connection"
PluginRespirator.connectToOtherPlugin: Improve JavaDoc
PluginTalker.connectToOtherPlugin(): Adapt to Client/Connection rename
PluginRespirator.getFCPPluginClientByID(): Client/Connection rename
PluginRespirator.getFCPPluginClientByID(): Rename to
getPluginConnectionByID()
FCPPluginClient: Fix excessive line length
FCPPluginClient.constructForUnitTest(): JavaDoc grammar improvement
FCPPluginConnection: Organize imports
FCPPluginConnection: Sort functions by importance
FCPPluginClientTracker: Adapt to "Client" -> "Connection" rename
FCPPluginClientTracker: JavaDoc
FCPPluginClientTracker: Adapt to "Client" -> "Connection" rename
FCPPluginClientTracker: Adapt to "Client" -> "Connection" rename
FCPluginClientTracker: Improve JavaDoc
FCPPluginClientTracker: Adapt to "Client" -> "Connection" rename
FCPPluginClientTracker: Rename to FCPPluginConnectionTracker
FCPServer: Adapt to "Client" -> "Connection" rename
FCPPluginClient: Rename to FCPPluginConnectionImpl
FCPPluginClientTest: Rename to FCPPluginConnectionImplTest
FCPConnectionHandler: Adapt to "Client" -> "Connection" rename
FCPPluginClientMessage: Fix textual reference to renamed function
FCPPluginClientMessage.run(): Rename clientConnection
Fix missed "FCPPluginClient" -> "FCPPluginConnectionImpl" renaming
FCPPluginClientMessage: Fix textual reference to renamed function
FCPPluginConnectionImpl: Fix missed JavaDoc link in variable rename
FCPConnectionHandler.getFCPPluginConnection(): Trim visibility
FCPPluginConnectionImplTest: Adapt to "Client" -> "Connection" rename
FCPPluginConnectionImpl: JavaDoc improvement
FCPPluginConnectionImpl: Fix spelling of "to outweigh"
FCPPluginConnectionImpl: JavaDoc fix
FCPPluginConnectionImpl: JavaDoc fix
FCPPluginConnectionImpl: JavaDoc fix
FCPPluginConnectionImpl: JavaDoc improvements
FCPPluginConnectionImpl.isServerDead(): JavaDoc improvements
Organize imports
FCPPluginConnectionImpl: Use parent interface as type when sensible
FCPPluginConnectionImpl: Adapt to "Client" -> "Connection" rename
FCPPluginConnectionImpl: Documentation improvement
FCPPluginConnectionImpl: Catch Error thrown by message handlers
FCPPluginConnectionImpl: Fix wrong Throwable type in error messages
FCPPluginConnectionImpl: Fix wrong Throwable type in documentation
FCPPluginConnectionImpl: Adapt to "Client" -> "Connection" rename
FCPPluginConnectionImpl: Unify logging
FCPPluginConnectionImpl: Use parent interface as type when sensible
FCPPluginConnectionImpl.sendSynchronous(): Unify error message format
FCPPluginConnectionImpl.toString(): Add "server" member variable
FCPPluginConnectionImpl: Use parent interface as type when sensible
FCPPluginConnection: Adapt to "Client" -> "Connection" rename
FCPPluginConnectionImpl: Adapt to "Client" -> "Connection" rename
FCPServer: Adapt to "Client" -> "Connection" rename
PluginRespirator.connectToOtherPlugin(): Improve JavaDoc readability
FCPPluginConnection: Add send functions with default SendDirection
FCPPluginConnectionImpl: Add member class DefaultSendDirectionAdapter
FCPPluginConnectionImpl: Fix grammar typo
FCPPluginConnectionImpl: Add member class SendToClientAdapter
FCPPluginConnectionImpl: Add member class SendToServerAdapter
FCPPluginConnectionImpl.SendToClientAdapter: Add "ATTENTION" to
JavaDoc
FCPPluginConnectionImpl: Add storage for DefaultSendDirectionAdapters
FCPPluginConnection: Remove getServerPluginName()
FCPPluginConnectionImpl.constructForUnitTest(): Compile-fix
FCPPluginConnectionImpl: Fix JavaDoc typo
FCPPluginConnectionImpl: Add getDefaultSendDirectionAdapter()
FCPPluginConnectionImpl: Implement send functions without
SendDirection
FCPPluginConnectionImpl: Pass DefaultSendDirectionAdapter
FCPPluginConnectionTracker: Add getConnectionWeakReference()
FCPPluginConnectionImpl.SendToClientAdapter: Optimize
FCPPluginConnectionTracker: Store FCPPluginConnection*Impl*
FCPServer: Set default send direction in returned FCPPluginConnections
FCPServer.createFCPPluginConnectionForIntraNodeFCP(): Trim return type
FCPServer.createFCPPluginConnectionForIntraNodeFCP(): Trim JavaDoc
type
FCPPluginConnectionImpl: Trim visibility
PluginRespirator: Organize imports.
FCPPluginConnectionImpl: Fix "SHOULD NOT HAPPEN: java.io.IOException:"
FCPPluginConnectionImpl: Add missing linebreaks to JavaDoc
FCPPluginConnectionImpl: Document that only adapters must be
handed out
FCPPluginConnection: Add missing linebreaks to JavaDoc
FCPPluginConnection: JavaDoc
FCPPluginConnection.send*(): Improve JavaDoc of SendDirection
parameter
ServerSideFCPMessageHandler: Allow keeping strong refs to connections
FCPPluginConnectionImpl: Detect bogus reply message identifiers
DefaultSendDirectionAdapter: Implement toString()
FCPPluginConnectionImpl: Fix NullPointerException
FCPPluginConnectionImpl: Detect non-reply replies
PluginRespirator.getPluginConnectionByID(): Linkify "connection"
PluginRespirator.getPluginConnectionByID(): JavaDoc
FCPPluginMessage: Fix too lax JavaDoc
FCPPluginConnectionImpl: Add performance TODO
FCPPluginConnectionTracker: JavaDoc
FCPPluginConnectionTracker: JavaDoc
FCPConnectionHandler: JavaDoc
Fix excessive JavaDoc indentation
Fix excessive JavaDoc indentation
Fix excessive JavaDoc indentation
Fix excessive JavaDoc indentation
Fix excessive JavaDoc indentation
Fix excessive JavaDoc indentation
Fix excessive JavaDoc indentation
PluginRespirator.getPluginConnectionByID(): JavaDoc fix
PluginManager.getPluginInfo(): Fix JavaDoc to say what it actually
does
FCPPluginConnectionImpl: Fix JavaDoc deadlink to removed function
FCPPluginConnectionImpl: Document planned isServerDead() removal
FCPPluginConnectionImpl: Add performance TODO
FCPPluginConnectionImpl: Remove redundant JavaDoc
PluginRespirator.connectToOtherPlugin(): Add null check
FCPPluginConnectionImpl: JavaDoc
FCPPluginConnectionImpl: JavaDoc
FCPPluginConnectionImpl: JavaDoc
FCPPluginConnectionImpl: Use "cause"-constructor of RuntimeException
PluginManager: JavaDoc
Toadlet.showAsToadlet(): Documentation tweaks
Toadlet.showAsToadlet(): Documentation tweaks
Document that the new plugin FCP API is unstable and might change
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Devl mailing list [email protected] https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
