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.
