On Mar 15, 11:37 am, Thadeus Burgess <thade...@thadeusb.com> wrote: > Why should we call it something different when the rest of the open > source community views it the same as we do? I mean, that is where we > got the definition of plugin, is from other open source projects.
Thadeaus is hitting the same mark we have hit before, I think. Wittgenstein said: "What we cannot speak about we must pass over in silence" - perhaps in this case, it's a corollary: "what we cannot agree on meaning for, we must pass over in disagreement" If you call what Sammy sees as "red", "yellow" - then there will be eternal arguments: "No that's not a dog; a dog does not have a trunk!" - not exactly passing over in silence, but consumed in confusion. The essence of the issue (as I recall) is: - a plugin is something called BY your application to perform some well defined function (e.g. "edit a page") This implies that the plugin must adhere to an interface. And that there are some well described rules for what "edit a page" constitutes. I think what Massimo seems to define most would understand as an application-level module (put it in separately from the code you write, and use it "like" a library you get from someone else; you call it, and read its documentation to see what it does). This, as I recall - and as appears (on casual observance of this thread) - this is the fundamental difference. The reason for this difference, and why it seems so hard to get to a plugin discussion... is not completely clear (perhaps Wittgenstein offers more insight?). - I must admit to having been exhausted by this argument the last time, so I have not looked in more depth than to recognize that this is the same "old dog." - Yarko > > Iin my research of pluggable systems you have the following architecture. > > Base System -> The Software > |-> PluginManager > |-> BasePlugin (interface) > \_Plugins > -> MyPlugin (inherits from BasePlugin) > > The base system, using the plugin manager, exposes pipes to the plugin > manager that can communicate with a plugin. > > Here is some example psuedocode. > > def admin_screen(): > if pluginmanager.plugin_overrides('admin_screen'): > pluginmanager.execute_plugin('admin_screen') > else: > pluginmanager.execute_pre('admin_screen') > # do normal stuff for admin > pluginmanager.execute_post('admin_screen') > > As you see, this allows plugins to either A) enhance functionality of > a method, or B) Override the method completely, like a signal/slot > system. > > As far as exposing hooks... that is a can of worms in and of it self, > but I can think of the basics > > DAL insert (audit module), > select(cache module), > update(audit/converter), > delete(audit/trashbin) > > On session create/destroy > On/after controller execute (i know, response._caller) > On pack_app (could add other optimizations to the compiled files?) > Admin, Crud, Cache, PLUGINS > > These all could hook into a signal/slot system, so that conceivably > they could all "talk" to other parts. > > I want to stress one thing about a "hooks" system for web2py. I want > the hooks system to be very minimalistic at best, there are lots of > things you don't need hooks for in web2py (do web frameworks need > complicated event systems?), but there are other things that just make > sense to be inside of a hook. > > -Thadeus > > On Mon, Mar 15, 2010 at 8:37 AM, mdipierro <mdipie...@cs.depaul.edu> wrote: > > Thadeus is right. We have gone over this before. We should use the > > work plugins ONLY for the current mechanism and use a more specific > > name for other types of objects people now refer to as plugins. > > > When I think about hooks I think of a CMS app for example and I would > > like to see a subset of current plugins designed specifically for a > > CSM app. > > > You are thinking of web2py hooks, something that never occurred to me. > > What kind of hooks would you like web2py to expose and how? > > > Massimo > > > On Mar 15, 8:34 am, Thadeus Burgess <thade...@thadeusb.com> wrote: > >> > plugins as they require by some kind of "plugin panel" or so... In deed, > >> > that is the meaning of "plug-ins", isn't it? > >> > But you must to share the plugins to be portable (as you say) maybe we > >> > are > >> > not talking about plugins at all...(but components). > > >> Massimo's definition of a plugin is not the same as our definition of a > >> plugin. > > >> This is an area of great vagueness, since there is no way we can talk > >> about a plugin system, if nobody understands what anyone else means by > >> the simple word "plugin". > > >> I don't think what we are trying to accomplish has anything to do with > >> plugins. To me, plugins enhance or add functionality by integrating > >> into HOOKS designated by the base system (web2py). But that is not the > >> case in what we are trying to do, basically, we are just wanting some > >> simple set of modular files with a convention that makes them portable > >> subsets of an application (not a plugin, but a portable sub package). > > >> -Thadeus > > >> On Mon, Mar 15, 2010 at 6:47 AM, Alex Fanjul <alex.fan...@gmail.com> wrote: > > >> > El 15/03/2010 10:40, mdipierro escribió: > > >> >> I understand the argument. Each of the system have pros and cons. > > >> >> If a plugin resides outside the app you have these problems: > >> >> 1) app would not be portable because plugins would not be packages > >> >> with it > > >> > I heard this argument many times from you Massimo, but I don't agree with > >> > that at all, let me explain. If we are talking about plugins (real > >> > plugins) > >> > you should be able to plug and unplug them at anytime without too much > >> > modifications (apart from maybe som general configurations of the > >> > plugin). > >> > Tipically web applications (and even desktop ones) doesn't come with the > >> > plugins packed in it, ie. think of Eclipse IDE, Firefox, Magento, > >> > Wordpress, > >> > etc. All of them have the ability to share the base and install as many > >> > plugins as they require by some kind of "plugin panel" or so... In deed, > >> > that is the meaning of "plug-ins", isn't it? > > >> > Then, you should be able to download my core/basic application from my > >> > website, and install the latest compatible version of the plugins I used > >> > to > >> > make the app. There could be even required plugins -why not-. > >> > But you must to share the plugins to be portable (as you say) maybe we > >> > are > >> > not talking about plugins at all...(but components). > > >> >> 2) there would be problems if different apps require different > >> >> versions of the same plugins > > >> > Typically the plugins folders comes in the form of "plugin_name-1.2.x", > >> > maybe this way they wouldn't interference each other. Each app is an > >> > independet one, so it's responsability of the developer use the version > >> > he > >> > can/wants for each app and update them if he can/wants. > > >> >> Anyway. You can do this already: > > >> >> Create an app called plugins > > >> >> web2py/applications/plugins > > >> >> Any other app can use the views and the static files of the plugins > >> >> installed under app plugins. Any other app can call services > >> >> implemented by actions of the plugins in app plugins. Any other app > >> >> can import modules defined by plugins in app plugins. > > >> >> Some care must be taken in designing plugins designed to be shared > >> >> since there must be a mechanism for passing a request/response/session/ > >> >> cache/T and databases to the plugin. > > >> >> We do not have specifications for this. This is not a technical issues > >> >> (no more than is there were in fact a web2py/plugins folder instead of > >> >> a web2py/applications/plugins) but an issue about conventions. Feel > >> >> free to make a proposal in this respect. > > >> >> Massimo > > >> >> On Mar 15, 4:15 am, selecta<gr...@delarue-berlin.de> wrote: > > >> >>> On Mar 13, 4:25 pm, mdipierro<mdipie...@cs.depaul.edu> wrote: > > >> >>>> If I understand you are asking for a web2py level plugin system vs an > >> >>>> app level plugin system. This has nothing to do with relocation of > >> >>>> plugins under an app subfolder. Am I correct? > > >> >>> Well maybe but consider the following > > >> >>> pseudo ls > >> >>> /app1/.cvs > >> >>> /app1/controller/.cvs > >> >>> /app1/controller/plugin_useradmin.py > > >> >>> /app2/.cvs > >> >>> /app2/controller/.cvs > >> >>> /app2/controller/plugin_useradmin.py > > >> >>> now the plug-in useradmin is under version control of app1 and app2 > >> >>> this means that the plug-in is under two different version control > >> >>> systems but if it would be like that > > >> >>> /app1/.cvs > >> >>> /app1/plugins/useradmin/controller/.cvs > >> >>> /app1/plugins/useradmin/controller/plugin_useradmin.py > > >> >>> /app2/.cvs > >> >>> /app2/plugins/useradmin/controller/.cvs > >> >>> /app2/plugins/useradmin/controller/plugin_useradmin.py > > >> >>> app1 and app2 could have seperate version control from the plug-in > > >> >>> I guess the problem could also be solved with at web2py level plugin > >> >>> system but this solution would be easier to handle since I do not have > >> >>> to mingle with setting things in the app so the plugin can use the > >> >>> same db as the app etc. > > >> > -- > >> > Alejandro Fanjul Fdez. > >> > alex.fan...@gmail.com > >> >www.mhproject.org > > >> > -- > >> > You received this message because you are subscribed to the Google Groups > >> > "web2py-users" group. > >> > To post to this group, send email to web...@googlegroups.com. > >> > To unsubscribe from this group, send email to > >> > web2py+unsubscr...@googlegroups.com. > >> > For more options, visit this group at > >> >http://groups.google.com/group/web2py?hl=en. > > > -- > > You received this message because you are subscribed to the Google Groups > > "web2py-users" group. > > To post to this group, send email to web...@googlegroups.com. > > To unsubscribe from this group, send email to > > web2py+unsubscr...@googlegroups.com. > > For more options, visit this group > > athttp://groups.google.com/group/web2py?hl=en. > > -- You received this message because you are subscribed to the Google Groups "web2py-users" group. To post to this group, send email to web...@googlegroups.com. To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/web2py?hl=en.