Re: [sensor-dev] Code checked in

[Age M. <age...@gm...>]

On 6/30/05, Richard Swart <rj...@gm...> wrote:
> >Why split this up ?
> >
> Because I anticipate that you want to have a different schedule
> frequency per type, but probably not per plugin. Splitting up the
> interface also means that plugins do not have to implement a sensor type
> if that does not make sense (e.g a VMdata plugin with only Gauges).

I think that's because you still think only in output plugins. But
(PULL) import plugins are just as important for pulling VM data, OS
data, etc into the core. And I think that the best fit would be a
plugin per source./target system, not per type. Otherwise you would
end up with a VM-timer plugin, a VM counter plugin, a VM gauge plugin,
an OD gauge plugin, etc.

> >I would use one export service and one import service that support
> >export/import for all supported sensor types.
> >
> >Plugins are just as important for importing data.
> >
> I still don't  see a  clear  case  for  a  push  model except for
> persisting data (which I don't see as part of the core).

I'm taling about pull importers. Push imports are another topic. I see
no reason to forbid push imports and with Spring it is really easy to
implement a push import by using an exporter plugin on one system that
connects (through xfire or whatever) to the input service on another
system. We don't have to do abythin special to support this and I
don't see the need to prevent it.

> It's more complicated than I had in mind with a separate crom expr per
> plugin. It is flexible but will also impact the gui for managing all
> these schedules, etc. Do we really need this?

--> optional <-- The plugin manager has a default cron expression and
if you want some plugins to run more often than other you can either
declare another plugin manager or set the cron expression of a
seperate plugin. Flexabillity.

> But I want the core also to behave as a plugin. Can't we have the export
> interface for the core and the plugin to be the same?

No, the output service is the only way to get data out of the core. It
defines an API and a set of domain objects. Exporters can request this
data and put it somewhere else but they should have no knowledge of
the internal implementation of the core.

Age