Comments on: Modelling a Plugin System http://www.advansen.com/2006/12/01/modelling-a-plugin-system/ Gabriel Gonzalez's notebook Mon, 25 Jan 2010 10:35:11 +0000 http://wordpress.org/?v=2.9.2 hourly 1 By: Gabriel Gonzalez http://www.advansen.com/2006/12/01/modelling-a-plugin-system/comment-page-1/#comment-289 Gabriel Gonzalez Mon, 29 Jan 2007 08:45:23 +0000 http://www.advansen.com/2006/12/01/modelling-a-plugin-system/#comment-289 Ah! Ok mate so you was talking about which functionalities could be extended in the future so you can from them develop the plugin subsystem :) Maybe you would enjoy a tiny entry I post at <a href="http://www.skyscrapr.net/blogs/solution/archive/2007/01/27/673.aspx" rel="nofollow">http://www.skyscrapr.net/blogs/solution/archive/2007/01/27/673.aspx</a> Ah! Ok mate so you was talking about which functionalities could be extended in the future so you can from them develop the plugin subsystem :)

Maybe you would enjoy a tiny entry I post at http://www.skyscrapr.net/blogs/solution/archive/2007/01/27/673.aspx

]]> By: Alejandro Espinoza http://www.advansen.com/2006/12/01/modelling-a-plugin-system/comment-page-1/#comment-288 Alejandro Espinoza Mon, 29 Jan 2007 02:23:53 +0000 http://www.advansen.com/2006/12/01/modelling-a-plugin-system/#comment-288 I think you misunderstood me.... but it is ok. Because what you just described is exactly what I had in mind. What I meant was that you need to decide what parts can be extensible, for example the Parser mechanism: PDF or DOC. Not extend the PDF mechanism, but the parser mechanism. I think you misunderstood me…. but it is ok. Because what you just described is exactly what I had in mind.

What I meant was that you need to decide what parts can be extensible, for example the Parser mechanism: PDF or DOC. Not extend the PDF mechanism, but the parser mechanism.

]]> By: Gabriel Gonzalez http://www.advansen.com/2006/12/01/modelling-a-plugin-system/comment-page-1/#comment-287 Gabriel Gonzalez Sat, 27 Jan 2007 12:28:52 +0000 http://www.advansen.com/2006/12/01/modelling-a-plugin-system/#comment-287 I think I got your point, but I do not agree. After you design and develop the system you shuldn't go to it everytime you need to add a new plug-in system, it should somehow be able to pass message through a well-defined API which will not change. Of course you can use stratage pattern or whatever you like more for achiving a plug-in system but if you are creating a new plug-in to store documents in PDF format you should just develop the subsystem from the given API e.g. "newDoc()", "title()", "author()", "sign()" and so on. You should not allow to extend this API since otherwise the point of having a plug-in system is blurred. If I have not got your point you can turn into spanish and try it again :) I think I got your point, but I do not agree. After you design and develop the system you shuldn’t go to it everytime you need to add a new plug-in system, it should somehow be able to pass message through a well-defined API which will not change.

Of course you can use stratage pattern or whatever you like more for achiving a plug-in system but if you are creating a new plug-in to store documents in PDF format you should just develop the subsystem from the given API e.g. “newDoc()”, “title()”, “author()”, “sign()” and so on.

You should not allow to extend this API since otherwise the point of having a plug-in system is blurred.

If I have not got your point you can turn into spanish and try it again :)

]]> By: Alejandro Espinoza http://www.advansen.com/2006/12/01/modelling-a-plugin-system/comment-page-1/#comment-286 Alejandro Espinoza Sat, 27 Jan 2007 07:28:47 +0000 http://www.advansen.com/2006/12/01/modelling-a-plugin-system/#comment-286 Yep, I agree documentation sucks, that is why Software Factories seems so interesting...anyways...sorry for not explaining myself correctly, but English is my second language and sometimes I use words that I shouldn't. What I meant with 'aspects extensibility' I meant: what parts/features of the software are going to be extensible. For example let's say you want to make a feature which parses files. You can make the File Parser aspect of the application extensible or interchangeable (maybe following an Strategy pattern). One plug in for PDF files and another for the DOC files. Yep, I agree documentation sucks, that is why Software Factories seems so interesting…anyways…sorry for not explaining myself correctly, but English is my second language and sometimes I use words that I shouldn’t.

What I meant with ‘aspects extensibility’ I meant: what parts/features of the software are going to be extensible.

For example let’s say you want to make a feature which parses files. You can make the File Parser aspect of the application extensible or interchangeable (maybe following an Strategy pattern). One plug in for PDF files and another for the DOC files.

]]> By: Gabriel Gonzalez http://www.advansen.com/2006/12/01/modelling-a-plugin-system/comment-page-1/#comment-284 Gabriel Gonzalez Sat, 27 Jan 2007 00:22:22 +0000 http://www.advansen.com/2006/12/01/modelling-a-plugin-system/#comment-284 Hey! Having feedback from community is a very nice feeling :) I agree with you that software == documentation, and that's not a bad point at all. I just find it a pia, having e.g. 5 documents to describe a whole plug-in system, but it it is just my point of view. I don't get your point of aspects extensibility, could you explain yourself better? Thank's a lot :) Hey! Having feedback from community is a very nice feeling :)

I agree with you that software == documentation, and that’s not a bad point at all. I just find it a pia, having e.g. 5 documents to describe a whole plug-in system, but it it is just my point of view.

I don’t get your point of aspects extensibility, could you explain yourself better?

Thank’s a lot :)

]]> By: Alejandro Espinoza http://www.advansen.com/2006/12/01/modelling-a-plugin-system/comment-page-1/#comment-238 Alejandro Espinoza Fri, 26 Jan 2007 07:56:46 +0000 http://www.advansen.com/2006/12/01/modelling-a-plugin-system/#comment-238 How about just setting the interfaces for such extensibility. The first thing to do is to define the aspects which are going to be extensible, after that just establish a contract which defines what the system requires from the plug in. Most certainly this kind of extensibility has to be established and defined in the analysis and design phase. Now regarding documentation, that is just the nature of software architecture and development. We need to document what we do. If those subsystems were not developed as plugins, they still have to be documented. So I don't think that is a bad point against plug in architectures, it is just the nature of development. How about just setting the interfaces for such extensibility. The first thing to do is to define the aspects which are going to be extensible, after that just establish a contract which defines what the system requires from the plug in.

Most certainly this kind of extensibility has to be established and defined in the analysis and design phase.

Now regarding documentation, that is just the nature of software architecture and development. We need to document what we do. If those subsystems were not developed as plugins, they still have to be documented. So I don’t think that is a bad point against plug in architectures, it is just the nature of development.

]]>