As I said. Everybody here wants something different. I am only concerned with allowing each of you to be able to provide a proof concept of what you want and not commit to implement any change in web2py that will be restrictive in the long term.
When I use the word "plugins" I just mean these: http://web2py.com/plugins I agree that we need "higher level plugins", i.e. as you say, things that implement an interface (or hooks as Thadeus says). I am not convinced that these hooks should be hard coded in web2py because it would be restrictive. Hooks should be conventions implemented at the application layer, not at the framework layer. Massimo On Mar 15, 1:33 pm, Yarko Tymciurak <[email protected]> wrote: > On Mar 15, 11:37 am, Thadeus Burgess <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> > > >> 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<[email protected]> wrote: > > > >> >>> On Mar 13, 4:25 pm, mdipierro<[email protected]> 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. > > >> > [email protected] > > >> >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 [email protected]. > > >> > To unsubscribe from this group, send email to > > >> > [email protected]. > > >> > 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 > > ... > > read more » -- You received this message because you are subscribed to the Google Groups "web2py-users" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/web2py?hl=en.
