Re: [RT] The Real Component Simplification
On Thursday 05 January 2006 23:37, Berin Loritsch wrote: I don't recall if we tested extending where the URLStreamHandlers are located using the |java.protocol.handler.pkgs system property. The general problem with the java.protocol.handler.pkgs is revolving around an obscure bug (which Sun will not fix) which gives the side effect that those protocol handlers MUST sit in system classloader (or higher), and that is somewhat troublesome for products like Cocoon. IMHO, a big pity, since one could have done so much funky stuff with URL handlers otherwise. The interesting thing around this is that the internal code that handles this probably been refactored so that an additional method call is introduced on the call stack. Reason, it looks at the callstack a couple of levels away and tries to determine the callee and use its classloader. But it is always seeing java.net.URL which classloader is null, so it calls ClassLoader.getSystemClassLoader(). I have been arguing over this since JDK1.2 came out, but Won't fix. is the categorical reply from Sun. Cheers Niclas
Re: [RT] The Real Component Simplification
Daniel Fagerstrom wrote: Decomponentization could start right away. Do you have any concrete examples of components that shouldn't be components? The XMLSerializer/XMLDeserializer combo is one of the best examples, I think. These shouldn't be components. If noone objects I'll do the changes for 2.2 - we already discussed this years ago :) Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [RT] The Real Component Simplification
Carsten Ziegeler wrote: Daniel Fagerstrom wrote: Decomponentization could start right away. Do you have any concrete examples of components that shouldn't be components? The XMLSerializer/XMLDeserializer combo is one of the best examples, I think. These shouldn't be components. If noone objects I'll do the changes for 2.2 - we already discussed this years ago :) Carsten +1 /Daniel
Re: [RT] The Real Component Simplification
Carsten Ziegeler wrote: Daniel Fagerstrom wrote: Decomponentization could start right away. Do you have any concrete examples of components that shouldn't be components? The XMLSerializer/XMLDeserializer combo is one of the best examples, I think. These shouldn't be components. Definitely! If noone objects I'll do the changes for 2.2 - we already discussed this years ago :) +1 Sylvain -- Sylvain WallezAnyware Technologies http://bluxte.net http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: [RT] The Real Component Simplification
Berin Loritsch wrote: Daniel Fagerstrom wrote: Decomponentization could start right away. Do you have any concrete examples of components that shouldn't be components? Pipeline (sure we have two implementations, but that doesn't mean it has to be a component) Five implementations. And I imagine after interface cleanup and for pipeline API, pipeline should stay component. URL interpretation ? Just about anything that is not a Processor, Generator, Transformer, Serializer, or Reader. You forgot Matchers, Selectors, and Actions. Every but small projects have bunch of those. Stores. Swapped very frequently, several implementations, and Cocoon's default is not the fastest gun in the west. Input/output modules. Tons of them. It is very simplistic view of the world to declare that only P/G/T deserve to be components. I'd even go as far as claim that P/G/T are implemented by cocoon users the *least* often compared to other interfaces. Vadim As to Processors, I see the following implementations: 1. current sitemap--complete with its matchers, selectors, actions, and tree processor 2. rails-like router The others are planned extension points that several people have written solutions for.
Re: [RT] The Real Component Simplification
Daniel Fagerstrom wrote: Carsten Ziegeler wrote: Daniel Fagerstrom wrote: Decomponentization could start right away. Do you have any concrete examples of components that shouldn't be components? The XMLSerializer/XMLDeserializer combo is one of the best examples, I think. These shouldn't be components. If noone objects I'll do the changes for 2.2 - we already discussed this years ago :) Carsten +1 +1 Vadim
Re: [RT] The Real Component Simplification
Vadim Gritsenko wrote: Berin Loritsch wrote: Daniel Fagerstrom wrote: Decomponentization could start right away. Do you have any concrete examples of components that shouldn't be components? Pipeline (sure we have two implementations, but that doesn't mean it has to be a component) Five implementations. And I imagine after interface cleanup and for pipeline API, pipeline should stay component. Not necessarily. Just because there are multiple implementations doesn't necessarily mean it is a component--or should be a component. There are some useful things we can do with a Pipeline such as using the Decorator pattern as opposed to inheritance to add features. Or we could use other OO tricks that just aren't possible or too difficult in a component environment. URL interpretation ? SourceResolver and company Just about anything that is not a Processor, Generator, Transformer, Serializer, or Reader. You forgot Matchers, Selectors, and Actions. Every but small projects have bunch of those. No, I left them out on purpose. Those are elements of the Sitemap--which is an implementation of the Processor. Stores. Swapped very frequently, several implementations, and Cocoon's default is not the fastest gun in the west. Ok. That works. Input/output modules. Tons of them. :/ I think that there are some better ways of dealing with this... But it is an extension point that is useful. It is very simplistic view of the world to declare that only P/G/T deserve to be components. I'd even go as far as claim that P/G/T are implemented by cocoon users the *least* often compared to other interfaces. Well, as da Vinci said, Simplicity is the ultimate sophistication. The key point of the decomponentization process is to reduce the number of extension points to the absolute practical minimum. By being brave about what we leave out, it forces us to think differently about other aspects of the system. I'm thinking way forward here.
Re: [RT] The Real Component Simplification
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 5 Jan 2006, Carsten Ziegeler wrote: Date: Thu, 05 Jan 2006 09:47:01 +0100 From: Carsten Ziegeler [EMAIL PROTECTED] Reply-To: dev@cocoon.apache.org To: dev@cocoon.apache.org Subject: Re: [RT] The Real Component Simplification Daniel Fagerstrom wrote: Decomponentization could start right away. Do you have any concrete examples of components that shouldn't be components? The XMLSerializer/XMLDeserializer combo is one of the best examples, I think. These shouldn't be components. If noone objects I'll do the changes for 2.2 - we already discussed this years ago :) +1 - -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDvTNaLNdJvZjjVZARArhBAKDyvZP0PJFPGOoumN3qNszdd+kWtACg4KHO deM/MQyF4esf76tP+m9wT14= =Os2u -END PGP SIGNATURE-
Re: [RT] The Real Component Simplification
Berin Loritsch wrote: Vadim Gritsenko wrote: Berin Loritsch wrote: Pipeline (sure we have two implementations, but that doesn't mean it has to be a component) Five implementations. And I imagine after interface cleanup and for pipeline API, pipeline should stay component. Not necessarily. Just because there are multiple implementations doesn't necessarily mean it is a component--or should be a component. There are some useful things we can do with a Pipeline such as using the Decorator pattern as opposed to inheritance to add features. Or we could use other OO tricks that just aren't possible or too difficult in a component environment. May be URL interpretation ? SourceResolver and company It proved to be very valuable extension point Just about anything that is not a Processor, Generator, Transformer, Serializer, or Reader. You forgot Matchers, Selectors, and Actions. Every but small projects have bunch of those. No, I left them out on purpose. Those are elements of the Sitemap--which is an implementation of the Processor. Stores. Swapped very frequently, several implementations, and Cocoon's default is not the fastest gun in the west. Ok. That works. Input/output modules. Tons of them. :/ I think that there are some better ways of dealing with this... But it is an extension point that is useful. Unified object model and expression language could replace many of those. It is very simplistic view of the world to declare that only P/G/T deserve to be components. I'd even go as far as claim that P/G/T are implemented by cocoon users the *least* often compared to other interfaces. Well, as da Vinci said, Simplicity is the ultimate sophistication. The key point of the decomponentization process is to reduce the number of extension points to the absolute practical minimum. By being brave about what we leave out, it forces us to think differently about other aspects of the system. I'm thinking way forward here. Just don't throw out baby in the heat of fight for simplification :) Vadim
Re: [RT] The Real Component Simplification
Vadim Gritsenko wrote: URL interpretation ? SourceResolver and company It proved to be very valuable extension point I'm not negating that, however the way it is currently implemented makes it difficult to use at times. Again there are different ways of skinning this particular cat that would be more efficient. I do recall why we didn't try to use Java's own URL component framework. It really wasn't due to complexity of getting the URLStreamHandlers to communicate with Cocoon. It was due to the fact that some web containers like BEA WebLogic and IBM WebSphere preset the static instance of URLStreamHandlerFactory, making it impossible for us to override it. I don't recall if we tested extending where the URLStreamHandlers are located using the |java.protocol.handler.pkgs system property. The advantage of using Java's extension mechanism here is that we would be able to use our cocoon:// URLs inside of FOP and any other library that relies on URLs. If we don't rely on components for the core of Cocoon, then we have more flexibility on improving this point. | It is very simplistic view of the world to declare that only P/G/T deserve to be components. I'd even go as far as claim that P/G/T are implemented by cocoon users the *least* often compared to other interfaces. Well, as da Vinci said, Simplicity is the ultimate sophistication. The key point of the decomponentization process is to reduce the number of extension points to the absolute practical minimum. By being brave about what we leave out, it forces us to think differently about other aspects of the system. I'm thinking way forward here. Just don't throw out baby in the heat of fight for simplification :) Right. Although just because something is an extension point does not mean it has to necessarily be a component.
Re: [RT] The Real Component Simplification
Carsten Ziegeler wrote: Daniel Fagerstrom wrote: Decomponentization could start right away. Do you have any concrete examples of components that shouldn't be components? The XMLSerializer/XMLDeserializer combo is one of the best examples, I think. These shouldn't be components. If noone objects I'll do the changes for 2.2 - we already discussed this years ago :) I never wrote avalon components for my cocoon needs. :-) Hence, any step to a simpler architecture deserves a big +1! Best Regards, Antonio Gallardo. Carsten
Re: [RT] The Real Component Simplification
Berin Loritsch skrev: ... Much like Photoshop with filter plugins. The block idea would be more analagous to complex macros for Photoshop. They may provide new plugins to use in the package, but they allow you to do predefined things. I don't know enough about Photoshop to be able to follow your analogy. Are you talking about extension points and plugins as in Eclipse or are you talking about some other level of granularity? ... The real component simplification is to get rid of the components that will never be swapped out. It's unnecessary for them to be components anyway. That makes the task of providing an Avalon bridge for existing components much easier. And it achieves the goal that the internals are not a scary mess any more. Decomponentization could start right away. Do you have any concrete examples of components that shouldn't be components? /Daniel
Re: [RT] The Real Component Simplification
Daniel Fagerstrom wrote: Berin Loritsch skrev: ... Much like Photoshop with filter plugins. The block idea would be more analagous to complex macros for Photoshop. They may provide new plugins to use in the package, but they allow you to do predefined things. I don't know enough about Photoshop to be able to follow your analogy. Are you talking about extension points and plugins as in Eclipse or are you talking about some other level of granularity? Pretty much. ... The real component simplification is to get rid of the components that will never be swapped out. It's unnecessary for them to be components anyway. That makes the task of providing an Avalon bridge for existing components much easier. And it achieves the goal that the internals are not a scary mess any more. Decomponentization could start right away. Do you have any concrete examples of components that shouldn't be components? Pipeline (sure we have two implementations, but that doesn't mean it has to be a component) URL interpretation Just about anything that is not a Processor, Generator, Transformer, Serializer, or Reader. As to Processors, I see the following implementations: 1. current sitemap--complete with its matchers, selectors, actions, and tree processor 2. rails-like router The others are planned extension points that several people have written solutions for.
