[dsdp-tml-dev] Re: Event/Listeners mechanism in instance registry

["Fabio Rigo" <fabio.rigo@xxxxxxxxx>]

Hello guys,

 

I've been taking a look at the device framework archtecture and wish to ask some questions:

1. There are both "managers" and "registries" (InstanceRegistry / InstanceManager for example). They seem to have quite similar functionality and structure (for example, both are singleton, public and handle with the same kind of data). What is the purpose of each of them?

2. Why are the "registries" inside a factory package?

3. Why is the instance persistency functionality inside the InstanceManager class? Shouldn't it be in a different package?

4. Shouldn't the model itself be encapsulated inside the framework, but exposing some public methods to read data from it?

 

I would like to firstly undestand the current archtecture, because depending on the answers we should think of a listener solution in different ways.

 

I was wondering that for adding listeners with the current archtecture, it will be needed to separate them in 2 groups:

- instanceCreated(IInstance) and instanceDeleted(IInstance) would be related to InstanceManager, because they deal with device existence/persistence. Maybe an additional instanceUpdated(IInstance) would fit here.

- instanceLoaded(IInstance) and instanceUnloaded(IInstance) would be related to InstanceRegisry, because they are related to model population.

I'm not sure if it would be better to have all methods in a single listener, which notification would be controlled by a single class, or if we should have the two listeners as described above.

 

Please tell me if any of those approaches are against to any idea or direction you already have.

 

Thanks,

Fabio

 

2008/8/18 Fabio Rigo <fabio.rigo@xxxxxxxxx>

Hello guys,

Do you have any ideas about the subject below?

Thanks,
Fabio Rigo

2008/7/30 Fabio Rigo <fabio.rigo@xxxxxxxxx>

Hi guys,

I was thinking about having event/listener support in device framework, which warns about events on instance registry.
An user could then register listeners for those events, that should have signatures like:

void instanceCreated(IInstance)
void instanceLoaded(IInstance)
void instanceUnloaded(IInstance)
void instanceDeleted(IInstance)

We should also extend this idea to the other registries in the framework.

What do you think?

Fabio Rigo