Newbie question: Is Hivemind well-suited for this task?

[mister bean]

I am deep into a project that reads in a data file, massages it, and writes out reports in various formats(spreadsheets, SVG chart, PDF, etc.). It currently uses plug-ins for the data massaging and for the various output formats. These plug-ins are JAR files that are loaded via a standard class loader.

Which plug-in to use when is determined by command-line switches. The code examines them and then loads, let's say, the PDF plugin. Because this is all done in code, it casts the plug-in location process into stone. I am about to externalize this step, by using an XML config file. (PDF output? Look up in the config file which plug-in JAR to use). This way, I can add new plugins and capabilities without having to change the code.

Before I make this change, I am beginning to wonder whether HiveMind would make better sense here. If so, what would it bring me that I don't get by using a simple XML config file? My sense is that HiveMind is probably overkill for what I need. But I would appreciate some thoughts from users before I commit to lots of time on the learning curve (rewarding as that might be ;-) to solve this specific problem.

Many thanks in advance.

---mr. bean

[Johan Lindquist]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

Hivemind does provide the plugability to you are looking for in the
sense that you could have each plug-in defined as a service and each
plug-in providing it's own information (for simplicity, the name and
service id ) to a central configuration (a configuration point) that can
be accessed at runtime by a plug-in lookup manager.  To load a
particular plug-in, it could use the plug-in name to lookup the
associated plug-in service id (from the configuration point).

I guess what this brings to you is a dynamic way of registering new
plugins, simply dropping in a new plug-in jar would automagically
register it in the system.  The command line switches could then, in
theory, be reduced to the user selecting the name of which plug-in to use.

Hope that helps somewhat.

Cheers,

Johan

mister bean wrote:
| I am deep into a project that reads in a data file, massages it, and
writes
| out reports in various formats(spreadsheets, SVG chart, PDF, etc.). It
| currently uses plug-ins for the data massaging and for the various output
| formats. These plug-ins are JAR files that are loaded via a standard class
| loader.
|
| Which plug-in to use when is determined by command-line switches. The code
| examines them and then loads, let's say, the PDF plugin. Because this
is all
| done in code, it casts the plug-in location process into stone. I am about
| to externalize this step, by using an XML config file. (PDF output?
Look up
| in the config file which plug-in JAR to use). This way, I can add new
| plugins and capabilities without having to change the code.
|
| Before I make this change, I am beginning to wonder whether HiveMind would
| make better sense here. If so, what would it bring me that I don't get by
| using a simple XML config file? My sense is that HiveMind is probably
| overkill for what I need. But I would appreciate some thoughts from users
| before I commit to lots of time on the learning curve (rewarding as that
| might be ;-) to solve this specific problem.
|
| Many thanks in advance.
|
| ---mr. bean
|
|


- --
you too?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHsuC/pHYnED7evioRAiwYAKCNf8w+Kzcy1kXhjmqEAWdowvUHOwCffshX
knEuo/Ryn5A+xJTKLsPJbYo=
=JW3T
-----END PGP SIGNATURE-----

[mister bean]

Thank you, Johan; that's very helpful. I appreciate it. ---mr. bean

Johan Lindquist wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

Hivemind does provide the plugability to you are looking for in the
sense that you could have each plug-in defined as a service and each
plug-in providing it's own information (for simplicity, the name and
service id ) to a central configuration (a configuration point) that can
be accessed at runtime by a plug-in lookup manager.  To load a
particular plug-in, it could use the plug-in name to lookup the
associated plug-in service id (from the configuration point).

I guess what this brings to you is a dynamic way of registering new
plugins, simply dropping in a new plug-in jar would automagically
register it in the system.  The command line switches could then, in
theory, be reduced to the user selecting the name of which plug-in to use.

Hope that helps somewhat.

Cheers,

Johan

mister bean wrote:
| I am deep into a project that reads in a data file, massages it, and
writes
| out reports in various formats(spreadsheets, SVG chart, PDF, etc.). It
| currently uses plug-ins for the data massaging and for the various output
| formats. These plug-ins are JAR files that are loaded via a standard class
| loader.
|
| Which plug-in to use when is determined by command-line switches. The code
| examines them and then loads, let's say, the PDF plugin. Because this
is all
| done in code, it casts the plug-in location process into stone. I am about
| to externalize this step, by using an XML config file. (PDF output?
Look up
| in the config file which plug-in JAR to use). This way, I can add new
| plugins and capabilities without having to change the code.
|
| Before I make this change, I am beginning to wonder whether HiveMind would
| make better sense here. If so, what would it bring me that I don't get by
| using a simple XML config file? My sense is that HiveMind is probably
| overkill for what I need. But I would appreciate some thoughts from users
| before I commit to lots of time on the learning curve (rewarding as that
| might be ;-) to solve this specific problem.
|
| Many thanks in advance.
|
| ---mr. bean
|
|


- --
you too?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHsuC/pHYnED7evioRAiwYAKCNf8w+Kzcy1kXhjmqEAWdowvUHOwCffshX
knEuo/Ryn5A+xJTKLsPJbYo=
=JW3T
-----END PGP SIGNATURE-----