On Wed, Feb 01, 2006 at 10:11:31AM +0100, Dennis Olsson wrote:
> >>
> >>So, basically SNMP + FCP + Advanced FCP (like in 'being able to get the
> >>raw data') would be sufficient for most tasks?
> >>In that case, the SNMP-tree I spoke about could be done, and in the end be
> >>1/3 of the final plugin system... which would have the ability to control:
> >>
> >>* statistics/settings/constants
> >>* sending/recieving data via FCP, without using sockets
> >>* sending/recieving 'raw' (I suggest somehow wrapped) data.
> >
> >There is no need to send/receive raw data, except conceivably for
> >migrating data between networks. I don't see how FCP can do anything
> >without a socket.
>
> We replace the socket (not for all applications, just the plugins) with a
> class that have the same methonds as the FCP has messages...
> for instance:
>
> public fcpClientGetReturnWrapper fcpClientGet(boolean IgnoreDS, boolean
> DSOnly, String URI int Verbosity,
> int ReturnType, int MaxSize,
> int MaxTempSize, int MaxRetries) {
> ...
> }
>
> The identifier is left out if implemented synced between the plugin and
> wrapper, then either sync or async. Sync is the easiest way to handle it
> for the plugin implemmenter.
Hmm, I see. Well, we do need to have a client-level java interface which
can either run inside or outside of Fred. I was thinking of this as
HighLevelSimpleClient though.
>
> >From what I can see this wouldn't be too hard to accomplish with the
> current code for FCP by just adding a new surface. Very much like
> FCPConnectionInputHandler, only method based instead of socket based.
>
> >>
> >>As I understand, you have already more or less implemented (2), and just
> >>putted a socket over the interface.
> >
> >I don't understand.
>
> I meant that you have the base for the above, and pretty much just added a
> socket/parser (FCPConnectionInputHandler and friends). This would ease the
> implementation of m-b (method based) FCP.
>
> >>
> >>Then, with SNMP, the plugin system is almost done already, except for (3)
> >>and the accual loading/handling of the plugins.
> >>
> >>What do you think of splitting the way to get hold of different functions?
> >>As in: one way to get stats, another to send basic data, and a third
> >>(maybe merged with the second in the end) to send special data.
> >
> >I still don't understand!
>
> We have 2/3 parts (argue with me if you think I'm wrong):
> * raw data (SNMP)
> * method based FCP
> * ??? (my first thought was 'advanced FCP', but is a third even needed? if
> we don't want plugins to write their own data, they simply have to wrap
> it in existing keys, making this part unnessesary.)
>
> So, if we remove the 'advanced FCP', there's two different ways for the
> plugin to communicate with the node.
>
> * SNMP via methods, to get/set stats/settings
> * FCP via methods to send/recieve data
>
> The first one is just a couple of hurs away from being completely
> accessable if we're going for the approach I wrote before
> (walkPath(String OID))
>
> The other one is 'just' a new interface to the FCP backend.
>
> The last thing (as in here.. not nessecarely as in implementation order)
> is to implement plugin loading/unloading.
>
>
> Is the approach above with two different systems for accessing the
> different parts of fred OK?
>
> Is my plans OK?
>
> If so, I believe that there might be a very basic plugin system working
> before next week.
Not bad yeah, though I'm not convinced we need yet another interface for
client functionality.
>
> // cyberdo
--
Matthew J Toseland - toad at amphibian.dyndns.org
Freenet Project Official Codemonkey - http://freenetproject.org/
ICTHUS - Nothing is impossible. Our Boss says so.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL:
<https://emu.freenetproject.org/pipermail/tech/attachments/20060201/93d806e2/attachment.pgp>
