jackcorless / jspf

Automatically exported from code.google.com/p/jspf
0 stars 0 forks source link

Convert internal PluginManager to some sort of kernel, and convert all internal services (locators, cache, ...) to plugins as well. #22

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago

A few notes:

1. Should only be done when it is clear what should happen with Pluglets
2. We should convert at least ClasspathManager, Loader and Cache. 
3. In that process, see if we can reduce internal complexity. 
4. Dump Meta-Handling aka Supervision?

Original issue reported on code.google.com by r.biedert on 16 Nov 2010 at 9:41

GoogleCodeExporter commented 8 years ago

Regarding 1)

Pro dumping:
In its current form the idea is flawed, as there is no simple way to 
distinguish and query various objects of the same class.  While 
getPlugin(Interface.class) works fine for multiple implementations that can be 
further identified using capabilities, sub-interfaces (or through suppression), 
several instances of the same class are too similar.

Contra dumping
On the other hand, we could introduce some @Identifier(id="x") method / 
variable tag. Pluglet authors could it to tag methods that return some value 
based on the pluglets status or initialization value. These could then be 
queried like

plugletManager.getPluglet(Interface.class, "x", "y")

so that the Pluglet is returned that implements Interface and has an ID label 
'x' returning the value 'y'.

Original comment by r.biedert on 16 Nov 2010 at 10:04

GoogleCodeExporter commented 8 years ago
Fixed priority.

Original comment by r.biedert on 16 Nov 2010 at 6:06

GoogleCodeExporter commented 8 years ago
4. Should be dumped. Adds complexity, we don't use it anymore, and has 
unresolved problems with complex return types.

Original comment by r.biedert on 17 Nov 2010 at 11:03

GoogleCodeExporter commented 8 years ago
Closing the whole issue. While 1., 3. and 4. appear to be valid, I think that 
2. takes lots of time and will not result in the benefits anticipated (e.g., 
simpler flow of code) due to the then necessary inter-plugin dependencies. 
Instead, we should focus on clearing up the innards of the .base. package.

Original comment by r.biedert on 17 Nov 2010 at 11:08