Read/write config variables require the config framework... if you want
to implement that, talk to me about it.
If the plugin system is too intimately tied to SNMP then you may as well
just include SNMP itself.
There are more plugins than diagnostics and config. In future we will
have transport plugins.
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
--
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/20060131/32ad2d45/attachment.pgp>
