On Wed, 1 Feb 2006, Matthew Toseland wrote:
> On Wed, Feb 01, 2006 at 01:55:23AM +0100, Dennis Olsson wrote:
>> 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).
>
> Config:
> - named variables and groups of variables with getters and setters
> (which will update them on the fly) included on registration.
> - config file parser/writer.
> - expose config vars via secure FCP. (secure FCP = passworded FCP).
> - expose config vars via HTTP.
Ok, doens't sound too difficult. With SNMP via methods instead of sockets,
this could be easily get/set from different parts within FRED.
>>
>>> 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.
>
> Hmm. I see...
>>
>>> 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.
>
> 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.
>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.
// cyberdo
>>
>> // cyberdo
>
