On Wed, 1 Feb 2006, Matthew Toseland wrote: ... >> >> 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.
That was _exactly_ what I was looking for.. Haven't checked it in detail yet, but seems good. If needed, it could be expanded with more methods in the future. >> ... >> 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. Ok, so we have HighLevelSimpleClient and I'll create a way for internal requests with SNMP. With Guerra's thread about requested features running for a couple of day we're probably set with what we need. I think we need for plugins to interact with fproxy also... suggestedly ia a directory (http://localhost:xxxx/_plugins/<registered name>/) Especially if we want features like anonymous webmail and stat-freaks to make own, internal, stat-pages. // cyberdo
