What's the right way to do this? - Part 2

[Guest]

Ok, I now have an application with plugins that can talk to it via a service
container. The next thing I'd like to be able to do is have the plugins be
able to pass data to each other through the main application (which will be
logging everything that gets passed between the plugins). I was thinking
that they could do this just by passing their data object along with its type
to a function in the main app, which could then pass it on to any plugin that
can handle that type of data. Here's where I'm running into trouble...

I need to have a way for the plugins to tell the main application what kinds
of data they can handle. Presumeably they would only handle types that
existing plugins create, and therefore the plugin developer would know about
them and know how to handle them. Once they tell the main app what they can
handle, the main app will know to pass that type of data on to them. Would
they just reference existing plugins and therefore gain access to their types
and be able to pass them to the main app to tell it that they can handle
those type? Any other ideas on how I should do this? Thanks!

 

[Matt Berther]

Hello Bagger,

Without any real specifics, you may want to look at the Observer [1] design
pattern. Your subject could provide an Attach and Detach method that would
register/unregister listeners. The Notify method would then provide notification
to all registered listeners passing along any context you desire.

[1] http://www.dofactory.com/Patterns/PatternObserver.aspx

 

[Guest]

Matt,

That looks like a good idea, but I'm not sure how to adapt it to my
situation. Let me run this past you and see what you think.

Keeping in mind that I'm loading the plugins dynamically during the main app
startup, it looks to me like the plugin developers would have to create a new
subject class for any data type that they create. Then the main app would
have to create a new subject object for each subject class that the plugin
defines (I guess it would have to scan the assembly for classes that inherit
from the abstract subject class). Then, anytime the main app creates a new
subject object, it would have to notify all the plugins about it so that they
could attach if they wish. I guess that anytime a new plugin is loaded, it
would have to try to attach to whichever subjects it needs. This is starting
to sound pretty complex to me now. Can it be made more simple and still work?

I was thinking about some kind of setup where the main app would just keep a
hashtable of plugins and the data types that they create and consume. The
real problem I was running into was how to make the data types available to
both the main app and all the plugins so that they can advertise or request
them. Does this sound doable, or am I just oversimplifying it? Thanks!

Hello Bagger,

Without any real specifics, you may want to look at the Observer [1] design
pattern. Your subject could provide an Attach and Detach method that would
register/unregister listeners. The Notify method would then provide notification
to all registered listeners passing along any context you desire.

[1] http://www.dofactory.com/Patterns/PatternObserver.aspx

--
Matt Berther
http://www.mattberther.com

Ok, I now have an application with plugins that can talk to it via a
service container. The next thing I'd like to be able to do is have
the plugins be able to pass data to each other through the main
application (which will be logging everything that gets passed between
the plugins). I was thinking that they could do this just by passing
their data object along with its type to a function in the main app,
which could then pass it on to any plugin that can handle that type of
data. Here's where I'm running into trouble...

I need to have a way for the plugins to tell the main application what
kinds of data they can handle. Presumeably they would only handle
types that existing plugins create, and therefore the plugin developer
would know about them and know how to handle them. Once they tell the
main app what they can handle, the main app will know to pass that
type of data on to them. Would they just reference existing plugins
and therefore gain access to their types and be able to pass them to
the main app to tell it that they can handle those type? Any other
ideas on how I should do this? Thanks!

 

[Matt Berther]

Hello Bagger,

I'm not sure what you mean by "data types". Do you mean object instances?
Can you provide a concrete example of what you're trying to accomplish?

--
Matt Berther
http://www.mattberther.com

Matt,

That looks like a good idea, but I'm not sure how to adapt it to my
situation. Let me run this past you and see what you think.

Keeping in mind that I'm loading the plugins dynamically during the
main app startup, it looks to me like the plugin developers would have
to create a new subject class for any data type that they create.
Then the main app would have to create a new subject object for each
subject class that the plugin defines (I guess it would have to scan
the assembly for classes that inherit from the abstract subject
class). Then, anytime the main app creates a new subject object, it
would have to notify all the plugins about it so that they could
attach if they wish. I guess that anytime a new plugin is loaded, it
would have to try to attach to whichever subjects it needs. This is
starting to sound pretty complex to me now. Can it be made more
simple and still work?

I was thinking about some kind of setup where the main app would just
keep a hashtable of plugins and the data types that they create and
consume. The real problem I was running into was how to make the data
types available to both the main app and all the plugins so that they
can advertise or request them. Does this sound doable, or am I just
oversimplifying it? Thanks!

Hello Bagger,

Without any real specifics, you may want to look at the Observer [1]
design pattern. Your subject could provide an Attach and Detach
method that would register/unregister listeners. The Notify method
would then provide notification to all registered listeners passing
along any context you desire.

[1] http://www.dofactory.com/Patterns/PatternObserver.aspx

--
Matt Berther
http://www.mattberther.com

Ok, I now have an application with plugins that can talk to it via a
service container. The next thing I'd like to be able to do is have
the plugins be able to pass data to each other through the main
application (which will be logging everything that gets passed
between the plugins). I was thinking that they could do this just
by passing their data object along with its type to a function in
the main app, which could then pass it on to any plugin that can
handle that type of data. Here's where I'm running into trouble...

I need to have a way for the plugins to tell the main application
what kinds of data they can handle. Presumeably they would only
handle types that existing plugins create, and therefore the plugin
developer would know about them and know how to handle them. Once
they tell the main app what they can handle, the main app will know
to pass that type of data on to them. Would they just reference
existing plugins and therefore gain access to their types and be
able to pass them to the main app to tell it that they can handle
those type? Any other ideas on how I should do this? Thanks!

 

[Guest]

Matt,

I think what I'm trying to say is that a plugin can produce pretty much any
kind of data to be consumed by other plugins. It could be an object that is
defined by the plugin author, or even a collection of objects, or it could be
an object that is already defined within the .NET framework. Pretty much
anything. I just need the main app to have some way to match up the plugins
that are distributing a particular type of data with the plugins that want to
receive that type of data. The part I'm having a hard time figuring out is
how the plugins that need to receive data should tell the main app what types
they want to receive. If the type is defined within another plugin, wouldn't
the receiving plugin have to reference the first one in order to tell the
main app what type it wants to receive?

Sorry if I'm not making much sense here. I'm still trying to get my head
around these design issues. I usually feel like I'm overcomplicating things
and that there has to be either a simpler or at least cleaner way to do
things. I just haven't found that way yet

Hello Bagger,

I'm not sure what you mean by "data types". Do you mean object instances?
Can you provide a concrete example of what you're trying to accomplish?

--
Matt Berther
http://www.mattberther.com

Matt,

That looks like a good idea, but I'm not sure how to adapt it to my
situation. Let me run this past you and see what you think.

Keeping in mind that I'm loading the plugins dynamically during the
main app startup, it looks to me like the plugin developers would have
to create a new subject class for any data type that they create.
Then the main app would have to create a new subject object for each
subject class that the plugin defines (I guess it would have to scan
the assembly for classes that inherit from the abstract subject
class). Then, anytime the main app creates a new subject object, it
would have to notify all the plugins about it so that they could
attach if they wish. I guess that anytime a new plugin is loaded, it
would have to try to attach to whichever subjects it needs. This is
starting to sound pretty complex to me now. Can it be made more
simple and still work?

I was thinking about some kind of setup where the main app would just
keep a hashtable of plugins and the data types that they create and
consume. The real problem I was running into was how to make the data
types available to both the main app and all the plugins so that they
can advertise or request them. Does this sound doable, or am I just
oversimplifying it? Thanks!

Hello Bagger,

Without any real specifics, you may want to look at the Observer [1]
design pattern. Your subject could provide an Attach and Detach
method that would register/unregister listeners. The Notify method
would then provide notification to all registered listeners passing
along any context you desire.

[1] http://www.dofactory.com/Patterns/PatternObserver.aspx

--
Matt Berther
http://www.mattberther.com
Ok, I now have an application with plugins that can talk to it via a
service container. The next thing I'd like to be able to do is have
the plugins be able to pass data to each other through the main
application (which will be logging everything that gets passed
between the plugins). I was thinking that they could do this just
by passing their data object along with its type to a function in
the main app, which could then pass it on to any plugin that can
handle that type of data. Here's where I'm running into trouble...

I need to have a way for the plugins to tell the main application
what kinds of data they can handle. Presumeably they would only
handle types that existing plugins create, and therefore the plugin
developer would know about them and know how to handle them. Once
they tell the main app what they can handle, the main app will know
to pass that type of data on to them. Would they just reference
existing plugins and therefore gain access to their types and be
able to pass them to the main app to tell it that they can handle
those type? Any other ideas on how I should do this? Thanks!

 

[Matt Berther]

Hello Bagger,

they want to receive. If the type is defined within another plugin,
wouldn't the receiving plugin have to reference the first one in order
to tell the main app what type it wants to receive?

Yes. These kind of reference requirements are probably best to be avoided
when designing a pluggable system. Surely you want each plugin to function
as an autonomous unit.

This leads me back to the second question of my previous post... Could you
provide a more concrete example of what you're trying to accomplish? This
could help in brainstorming another solution to your problem.

 

[Guest]

Yes, I would like them to be as autonomous as possible. Basically, what I'm
trying to build is a tool platform. The individual tools will be plugins,
and the main application will provide logging both for itself and for the
plugins, as well as message passing functionality. The idea is that someone
can build a plugin to do whatever task they need, and it will be run within
the main application (in an MDI setup) and be monitored by it. The main app
provides some other features as well, such as keeping track of different sets
of plugins used for different tasks. Some plugins may consume data generated
by other plugins in order to provide a meaningful display of some sort.
That's why they need to be able to specify what sort of data they want to
receive. Everything that gets communicated needs to go through the main app
and be logged.

The service container seems to work well for the communication between
plugins and the main application, the tough part now is figuring out how to
allow the plugins to pass data to each other through the main application
without making a mess of things. A plugin needs to be able to tell the main
application what kind of data it can offer, and also which kinds it can
consume.

Is that a better explanation? Let me know if I'm not making sense or giving
enough detail. Thanks!