[melkjug-dev] plugins, component architectures zope/trac oh my

[Luke Tucker]

I'm shopping around a bit for component frameworks for melkjug's
plugins ( http://oss.openplans.org/melkjug/wiki/PluginPoints ) and I'd
like to hear your input if you have a sec.

I feel like Trac's component model is all I really want at the moment,
but I haven't used it extensively in practice. I really like the
straightforwardness of it, the digestibility of the overall concept
and the limited scope -- drawback is afaict it is not packaged
separately (although it looks like the code is very orthogonal to the
rest of trac and it wouldn't be hard to take) Jeff, I think you might
have the most to say about what you like/dislike about Trac's model
and/or it's re-use. See http://trac.edgewall.org/wiki/TracDev/ComponentArchitecture

As Josh reminded me, we also have a ton of internal ZCA knowledge, so
I figured I should do a little due diligence on that front too...
Melkjug already uses a smattering of ZCA to document interfaces in the
model. Personally, I find ZCA to be a bit zany and overwrought for
what I'm intending -- the documentation makes my eyes want to glaze
over even though I already understand it... That said, it's cruft is
grown from battle worn use cases and it's clearly got some momentum
and backing as an independent framework.

Maybe all I want to do is paper over the foul details of ZCA that I
don't care about with something that behaves conceptually like Trac's
model for the 99% case (use ZCA as a meta-meta-framework) but let the
machinery hang out ... juuust in case.

Anything else I should be looking at? Thoughts?

- Luke



--
Archive: http://www.openplans.org/projects/melkjug/lists/melkjug-development-list/archive/2009/04/1239648863049
To unsubscribe send an email with subject "unsubscribe" to melkjug-dev-***@public.gmane.org Please contact melkjug-dev-manager-ZwoEplunGu1pszqg2B6Wd0B+***@public.gmane.org for questions.

[Jeff Hammel]

I'm shopping around a bit for component frameworks for melkjug's plugins
( http://oss.openplans.org/melkjug/wiki/PluginPoints ) and I'd like to
hear your input if you have a sec.
I feel like Trac's component model is all I really want at the moment,
but I haven't used it extensively in practice. I really like the
straightforwardness of it, the digestibility of the overall concept and
the limited scope -- drawback is afaict it is not packaged separately
(although it looks like the code is very orthogonal to the rest of trac
and it wouldn't be hard to take) Jeff, I think you might have the most
to say about what you like/dislike about Trac's model and/or it's re-use.
See http://trac.edgewall.org/wiki/TracDev/ComponentArchitecture

I would say that if you want a simple component architecture, then Trac is a very good model. Extension points are defined, plugins implement an interface which is plugged into extension points. It works very well for Trac.

As Josh reminded me, we also have a ton of internal ZCA knowledge, so I
figured I should do a little due diligence on that front too... Melkjug
already uses a smattering of ZCA to document interfaces in the model.
Personally, I find ZCA to be a bit zany and overwrought for what I'm
intending -- the documentation makes my eyes want to glaze over even
though I already understand it... That said, it's cruft is grown from
battle worn use cases and it's clearly got some momentum and backing as
an independent framework.

What Trac misses is adaptation, mostly. Also, you can't have composite interfaces, though this is an implementation detail. ExtensionPoints get turned into lists of components, which is a bit sloppy if you want to asser that exactly one gets used. But this is probably okay as you can always throw in assert statements. Again, I'd say adaptation is the main missing thing. If you can live without it, you're probably good.

Maybe all I want to do is paper over the foul details of ZCA that I
don't care about with something that behaves conceptually like Trac's
model for the 99% case (use ZCA as a meta-meta-framework) but let the
machinery hang out ... juuust in case.
Anything else I should be looking at? Thoughts?
- Luke

Just to throw a zany idea I've been thinking about, implicit interfaces vs explicit. Instead of marking things as implementing other things, you give rules by which a component is said to implement an interface. But since you want something simple, probably doing something experimental like this might not be the best.

Jeff


--
Archive: http://www.openplans.org/projects/melkjug/lists/melkjug-development-list/archive/2009/04/1239649263549
To unsubscribe send an email with subject "unsubscribe" to melkjug-dev-***@public.gmane.org Please contact melkjug-dev-manager-ZwoEplunGu1pszqg2B6Wd0B+***@public.gmane.org for questions.

[Robert Marianski]

Post by Jeff Hammel

I'm shopping around a bit for component frameworks for melkjug's plugins
( http://oss.openplans.org/melkjug/wiki/PluginPoints ) and I'd like to
hear your input if you have a sec.
I feel like Trac's component model is all I really want at the moment,
but I haven't used it extensively in practice. I really like the
straightforwardness of it, the digestibility of the overall concept and
the limited scope -- drawback is afaict it is not packaged separately
(although it looks like the code is very orthogonal to the rest of trac
and it wouldn't be hard to take) Jeff, I think you might have the most
to say about what you like/dislike about Trac's model and/or it's re-use.
See http://trac.edgewall.org/wiki/TracDev/ComponentArchitecture

I would say that if you want a simple component architecture, then Trac is a very good model. Extension points are defined, plugins implement an interface which is plugged into extension points. It works very well for Trac.

I haven't really used the trac model, so I can't speak to the
differences.

Post by Jeff Hammel

As Josh reminded me, we also have a ton of internal ZCA knowledge, so I
figured I should do a little due diligence on that front too... Melkjug
already uses a smattering of ZCA to document interfaces in the model.
Personally, I find ZCA to be a bit zany and overwrought for what I'm
intending -- the documentation makes my eyes want to glaze over even
though I already understand it... That said, it's cruft is grown from
battle worn use cases and it's clearly got some momentum and backing as
an independent framework.

What Trac misses is adaptation, mostly. Also, you can't have composite interfaces, though this is an implementation detail. ExtensionPoints get turned into lists of components, which is a bit sloppy if you want to asser that exactly one gets used. But this is probably okay as you can always throw in assert statements. Again, I'd say adaptation is the main missing thing. If you can live without it, you're probably good.

There's a conversation about application configuration going on in the
pypes project too:
http://www.openplans.org/projects/pypefitters/lists/pypefitters-discussion/archive/2009/04/1239260482813/forum_view#1239509309917

Post by Jeff Hammel

Maybe all I want to do is paper over the foul details of ZCA that I
don't care about with something that behaves conceptually like Trac's
model for the 99% case (use ZCA as a meta-meta-framework) but let the
machinery hang out ... juuust in case.
Anything else I should be looking at? Thoughts?
- Luke

I'd say to use the simplest thing that works. If you do go with the zca,
I think you're right to just paper over the details that you don't care
about. If you want to use xml as the configuration language, it may be a
little bit of work to reuse the xml parsing of zope.configuration. I
believe that the repoze guys created a new package, repoze.zcml, because
zope.configuration expects zope.security, which I think pulls in a lot
more packages. But if you don't want xml configuration, then the
provideAdapter and provideUtility calls should work for you if you use
the zca.

Post by Jeff Hammel
Just to throw a zany idea I've been thinking about, implicit interfaces vs explicit. Instead of marking things as implementing other things, you give rules by which a component is said to implement an interface. But since you want something simple, probably doing something experimental like this might not be the best.
Jeff

Interesting idea. Would this happen at startup time with something like
martian?

Robert


--
Archive: http://www.openplans.org/projects/melkjug/lists/melkjug-development-list/archive/2009/04/1239652913061
To unsubscribe send an email with subject "unsubscribe" to melkjug-dev-***@public.gmane.org Please contact melkjug-dev-manager-ZwoEplunGu1pszqg2B6Wd0B+***@public.gmane.org for questions.

[Jeff Hammel]

Post by Robert Marianski

Post by Jeff Hammel

I'm shopping around a bit for component frameworks for melkjug's plugins
( http://oss.openplans.org/melkjug/wiki/PluginPoints ) and I'd like to
hear your input if you have a sec.
I feel like Trac's component model is all I really want at the moment,
but I haven't used it extensively in practice. I really like the
straightforwardness of it, the digestibility of the overall concept and
the limited scope -- drawback is afaict it is not packaged separately
(although it looks like the code is very orthogonal to the rest of trac
and it wouldn't be hard to take) Jeff, I think you might have the most
to say about what you like/dislike about Trac's model and/or it's re-use.
See http://trac.edgewall.org/wiki/TracDev/ComponentArchitecture

I would say that if you want a simple component architecture, then Trac is a very good model. Extension points are defined, plugins implement an interface which is plugged into extension points. It works very well for Trac.

I haven't really used the trac model, so I can't speak to the
differences.

Post by Jeff Hammel

As Josh reminded me, we also have a ton of internal ZCA knowledge, so I
figured I should do a little due diligence on that front too... Melkjug
already uses a smattering of ZCA to document interfaces in the model.
Personally, I find ZCA to be a bit zany and overwrought for what I'm
intending -- the documentation makes my eyes want to glaze over even
though I already understand it... That said, it's cruft is grown from
battle worn use cases and it's clearly got some momentum and backing as
an independent framework.

What Trac misses is adaptation, mostly. Also, you can't have composite interfaces, though this is an implementation detail. ExtensionPoints get turned into lists of components, which is a bit sloppy if you want to asser that exactly one gets used. But this is probably okay as you can always throw in assert statements. Again, I'd say adaptation is the main missing thing. If you can live without it, you're probably good.

There's a conversation about application configuration going on in the
http://www.openplans.org/projects/pypefitters/lists/pypefitters-discussion/archive/2009/04/1239260482813/forum_view#1239509309917

Post by Jeff Hammel

Maybe all I want to do is paper over the foul details of ZCA that I
don't care about with something that behaves conceptually like Trac's
model for the 99% case (use ZCA as a meta-meta-framework) but let the
machinery hang out ... juuust in case.
Anything else I should be looking at? Thoughts?
- Luke

I'd say to use the simplest thing that works. If you do go with the zca,
I think you're right to just paper over the details that you don't care
about. If you want to use xml as the configuration language, it may be a
little bit of work to reuse the xml parsing of zope.configuration. I
believe that the repoze guys created a new package, repoze.zcml, because
zope.configuration expects zope.security, which I think pulls in a lot
more packages. But if you don't want xml configuration, then the
provideAdapter and provideUtility calls should work for you if you use
the zca.

Post by Jeff Hammel
Just to throw a zany idea I've been thinking about, implicit interfaces vs explicit. Instead of marking things as implementing other things, you give rules by which a component is said to implement an interface. But since you want something simple, probably doing something experimental like this might not be the best.
Jeff

Interesting idea. Would this happen at startup time with something like
martian?
Robert

I don't know martian so i can't speak to it. That's also an implementation detail though, yeah, caching interfaces at startup would be a good first step.

Jeff


--
Archive: http://www.openplans.org/projects/melkjug/lists/melkjug-development-list/archive/2009/04/1239653038507
To unsubscribe send an email with subject "unsubscribe" to melkjug-dev-***@public.gmane.org Please contact melkjug-dev-manager-ZwoEplunGu1pszqg2B6Wd0B+***@public.gmane.org for questions.