On Tue, 31 Jan 2006, Matthew Toseland wrote:
> Read/write config variables require the config framework... if you want
> to implement that, talk to me about it.
Well.. the config framework... No comment there.. Depends on the rest of
the SNMP/plugin-work (amount of it).
>
> If the plugin system is too intimately tied to SNMP then you may as well
> just include SNMP itself.
yes, that's true.. My goal is to use the SNMP-strategy for all
variable/statistics/constant-fetching and -witing, and then just (by the
help of "oc2c.walkPath(".1.3.1.1.0.0");" in the example) have an easy way
to get/set the value from within a plugin.
So, it'll pretty much be a nicer form of SNMP. Without all X-coding.
>
> There are more plugins than diagnostics and config. In future we will
> have transport plugins.
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.
As I understand, you have already more or less implemented (2), and just
putted a socket over the interface.
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.
// cyberdo
>
> On Tue, Jan 31, 2006 at 10:49:11PM +0100, Dennis Olsson wrote:
>> Hi all!
>>
>> I'm about to start on the plugin system and would like to get some
>> feedback on my thoughts.
>>
>> My plan:
>> 1) make a containerclass for similar functions
>>
>> 2) make a containerclass that can access all possibly needed stuff for a
>> category
>>
>> 3) make a containerclass for all those classes, making then accessible via
>> only one object
>>
>> 4) for each plugin loaded, initialize it with (3) as argument
>>
>>
>> The whole thing would look very much like a tree having (3) as the root,
>> and then subcategories in several layers. (NOT limited to 3 levels as
>> above).
>>
>>
>> : : : SNMP : : :
>>
>> I've implemented the basics for SNMP (the server and some
>> interfaces/classes), and I must say that I'm no expert... BUT:
>>
>> I know that SNMP is tree based, having ".1.3" as root, and then branches
>> out to different objects.
>>
>> My idea for the plugin system s similar. If the plugin would like, for
>> instance, the bytecount of all sent data, it'd get the object at the path
>> ".1.3.1.1.0.0" (this is identical to the SNMP). and then issue a
>> "getData()" to retrieve the object containing the data.
>>
>> Code:
>> = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
>> og2c = object_given_to_the_constructor;
>> DataContainer dc = oc2c.walkPath(".1.3.1.1.0.0");
>> System.out.print("Total accessed bytes: " + dc.getData());
>> = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
>>
>> The path (".1.3.1.1.0.0") would preferrably be set in a -public static
>> final String- in a well known class, making it changeable, and exportable
>> to a MIB.
>>
>> Pros:
>> * This way, all basic data can be accessed (read), and also written.
>> * The structure is closely tied to SNMP (pro?... well.. at least not con)
>> * The tree structure makes the data easily traversable... for instance,
>> getting all data with path starting with ".1.3.1.1" (currently: all
>> BW-stats) would be _very_ easy.
>> * It'd be extremely simple to implement.
>>
>> Cons:
>> * In it's simplest state, limited to Strings and Integers, reads and
>> writes.
>> * The tree-structure is mem-consuming if all containers keep a lot of
>> variables. (Even a true problem? With 256 bytes/node, 4k nodes is 1MB)
>> * The String-identifiers could be a pain. Replace with byte[]/int[]?
>>
>>
>> Questions:
>> * What could be expected that plugins want to do?
>> * Is the above structure good, if more functions then getData() and
>> setData() was implemented?
>> * Which functions in that case? addNotifiable(), open(), getTrueObject().
>>
>>
>> The more standardized it is, for instance by limiting it to Strings and
>> Integers, the more clean it'll become and easier to manage.
>> The downside is that it's limiting for all plugin implementors.
>>
>>
>> Also: Would it be a waste of time implementing the above for easier tasks
>> as getting RAM usage and setting BWLimit live and so on, and then perhaps
>> add another, more or less similar system, for more core-stuff...
>>
>> What would that be in that case? FCP via method calls?
>>
>> // Dennis (cyberdo)
>> _______________________________________________
>> Tech mailing list
>> Tech at freenetproject.org
>> http://emu.freenetproject.org/cgi-bin/mailman/listinfo/tech
>
>
