sensor-developer

[sensor-dev] Code checked in

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

Yo,

I didn't have much time this weekend but I managed to checkin my
experimental core code. The CVS structure as of now looks like this:

<cvsroot>/sensor/sensor-core

So just checkout the "sensor" module and you're set. The sensor-core
project is an eclipse project with a generated (by mevenide) and
edited maven project file. I tried the maven build and it works fine,
which is pretty easy since there are no build dependencies yet :)

What is there:

- The basis for the internal storage stuff in the "internal" package
- Some empty interfaces for the public API

The code is full of todos and source code comments so just check it
out and tell me what you think.

Age

PS
The sourceforge CVS stuff is pretty well documented. You'll have to go
through the public key exchange process before you can checkout the
code as a developer instead of anonymously. All current (known)
readers of this list are developers on the project and should have
write access.

Re: [sensor-dev] Code checked in

[Richard S. <rj...@gm...>]

Hi Age, Jurjan,

The tree concept looks interesting and powerful (as far as I understand 
it). I suppose you want to expose this through the admin  interface (so 
we will need a tree viewer?) . In a way this makes everything a little 
bit more complicated (or advanced) a I anticipated.

I played a little bit with the plugin idea. Probably the easiest way to 
do this is to use Spring. The idea is as follows:

- We'll have scheduled jobs per sensor type. One for Timers, one for 
Counters, one for Gauges.
- Each job will take (through dependency injection) a list of beans that 
implements either a TimerDataExportService,  CounterDataExportService, 
......
- The job will iterate through the list of injected beans and will call 
getDataAndReset() and persist the data.

This way we can plug any component implementing one (or all) Export 
interfaces just by adding them to the spring config (probably a separate 
one just for this) . Would this be flexible enough? Any drawbacks?

As a next step I propose we focus on defining the import, export and 
admin interface. After this Age could continue to concentrate on the 
core stuff (assuming he likes that) and Jurjan and I can work on some 
other items.

Richard

Age Mooy wrote:

>Yo,
>
>I didn't have much time this weekend but I managed to checkin my
>experimental core code. The CVS structure as of now looks like this:
>
><cvsroot>/sensor/sensor-core
>
>So just checkout the "sensor" module and you're set. The sensor-core
>project is an eclipse project with a generated (by mevenide) and
>edited maven project file. I tried the maven build and it works fine,
>which is pretty easy since there are no build dependencies yet :)
>
>What is there:
>
>- The basis for the internal storage stuff in the "internal" package
>- Some empty interfaces for the public API
>
>The code is full of todos and source code comments so just check it
>out and tell me what you think.
>
>Age
>
>PS
>The sourceforge CVS stuff is pretty well documented. You'll have to go
>through the public key exchange process before you can checkout the
>code as a developer instead of anonymously. All current (known)
>readers of this list are developers on the project and should have
>write access.
>
>
>-------------------------------------------------------
>SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
>from IBM. Find simple to follow Roadmaps, straightforward articles,
>informative Webcasts and more! Get everything you need to get up to
>speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click
>_______________________________________________
>Sensor-developer mailing list
>Sen...@li...
>https://lists.sourceforge.net/lists/listinfo/sensor-developer
>
>  
>

Re: [sensor-dev] Code checked in

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

On 6/29/05, Richard Swart <rj...@gm...> wrote:
> Hi Age, Jurjan,
>=20
> The tree concept looks interesting and powerful (as far as I understand
> it). I suppose you want to expose this through the admin  interface (so
> we will need a tree viewer?) . In a way this makes everything a little
> bit more complicated (or advanced) a I anticipated.

I'm still doubting whether to expose (a copy of) the internal
structure to the export service (as the data model for the reporting
side) or to implement that seperately. The internals are optimized for
multi-threaded access while the reporting stuff is read-only. As I see
it now, there are three or four seperate forms of sensor data:

- Input handles from the input service (timer, Counter, Gauge). They
are simple proxies for the internal SensorData
implementations.Write-only
- the internal SensorData implementations themselves. Optimized for
multi-threaded access. Read-write
- Export data. Read-only but close to the structure of the internal
SensorData implementations
- Import Data. Write only data pulled from other systems that has to
be stored in the internals

Importers cannot just use input handles like Timer to import data into
the core. They already have the full data, which they have to convert
to some standard type and store in the core.

I'm still thinking about this stuff, Suggestions are welcome.

> I played a little bit with the plugin idea. Probably the easiest way to
> do this is to use Spring. The idea is as follows:
>=20
> - We'll have scheduled jobs per sensor type. One for Timers, one for
> Counters, one for Gauges.

Why split this up ?

> - Each job will take (through dependency injection) a list of beans that
> implements either a TimerDataExportService,  CounterDataExportService,
> ......

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.

> - The job will iterate through the list of injected beans and will call
> getDataAndReset() and persist the data.

The scheduler can be configured with a list of plugins. These can be
importers or exporters, this doesn't matter to the plugin scheduler.
Each plugin can optionally be configured with a seperate cron
expression from the default one. The scheduler simple runs the plugins
when they ned to be run. Each plugin has a reference to either the
import service or the export service and is responsible for
transforing imported data to the correct model and exported model data
to the target system model..

> This way we can plug any component implementing one (or all) Export
> interfaces just by adding them to the spring config (probably a separate
> one just for this) . Would this be flexible enough? Any drawbacks?

See above. Obviously we will need one more service, bringing our total
list to the following:

- input service (managed, active input)
- import service (direct, passive input)
- output serivce (getting data out of the core)
- admin service (configuring and administering the core)

plus these interfaces:

- SensorDataImportPlugin
- SensorDataExportPlugin

These both extend the SensorDataPlugin interface

> As a next step I propose we focus on defining the import, export and
> admin interface. After this Age could continue to concentrate on the
> core stuff (assuming he likes that) and Jurjan and I can work on some
> other items.

Like I said above, I'm currently thinking about the interfaces that
hover around the core. Any new idea will be reported here :)

Age

Re: [sensor-dev] Code checked in

[Richard S. <rj...@gm...>]

Age Mooy wrote:

>  
>
>>I played a little bit with the plugin idea. Probably the easiest way to
>>do this is to use Spring. The idea is as follows:
>>
>>- We'll have scheduled jobs per sensor type. One for Timers, one for
>>Counters, one for Gauges.
>>    
>>
>
>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).

>>- Each job will take (through dependency injection) a list of beans that
>>implements either a TimerDataExportService,  CounterDataExportService,
>>......
>>    
>>
>
>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).

>>- The job will iterate through the list of injected beans and will call
>>getDataAndReset() and persist the data.
>>    
>>
>
>The scheduler can be configured with a list of plugins. These can be
>importers or exporters, this doesn't matter to the plugin scheduler.
>Each plugin can optionally be configured with a seperate cron
>expression from the default one. The scheduler simple runs the plugins
>when they ned to be run. Each plugin has a reference to either the
>import service or the export service and is responsible for
>transforing imported data to the correct model and exported model data
>to the target system model..
>
>  
>
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? 

>>This way we can plug any component implementing one (or all) Export
>>interfaces just by adding them to the spring config (probably a separate
>>one just for this) . Would this be flexible enough? Any drawbacks?
>>    
>>
>
>See above. Obviously we will need one more service, bringing our total
>list to the following:
>
>- input service (managed, active input)
>- import service (direct, passive input)
>- output serivce (getting data out of the core)
>- admin service (configuring and administering the core)
>
>plus these interfaces:
>
>- SensorDataImportPlugin
>- SensorDataExportPlugin
>
>These both extend the SensorDataPlugin interface
>
>  
>
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?

>>As a next step I propose we focus on defining the import, export and
>>admin interface. After this Age could continue to concentrate on the
>>core stuff (assuming he likes that) and Jurjan and I can work on some
>>other items.
>>    
>>
>
>Like I said above, I'm currently thinking about the interfaces that
>hover around the core. Any new idea will be reported here :)
>
>Age
>
>
>-------------------------------------------------------
>SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
>from IBM. Find simple to follow Roadmaps, straightforward articles,
>informative Webcasts and more! Get everything you need to get up to
>speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click
>_______________________________________________
>Sensor-developer mailing list
>Sen...@li...
>https://lists.sourceforge.net/lists/listinfo/sensor-developer
>
>  
>

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