On Wed, Oct 21, 2009 at 11:41 AM, mdipierro <mdipie...@cs.depaul.edu> wrote:

>
> This is up to the developer. You can choose to store all plugins in
> one app and have other apps call them
>

*sigh*


>
> {{=LOAD(...,application='otherapp')}}
>
> The fact is that if you distribute or compile an app, all plugins
> should stay with it.


"should"?  Several cases in point:

- shared libraries are not distributed (and consider the reasons that exists
over static linking)
- Firefox is NOT distributed with all plugins - the end user adds those he
wants to use (think of the reasons);
- a "survey" plugin.... how will it be added by the person who downloads a
(for example) wiki app?

The entire concept of "plugin" and it's purposes, and motivation needs to be
explicit.

I am concerned we do not be holding a mouse and calling it a tiger...




> Moreover it should be possible for two apps to
> use two different version of the same plugins since we cannot
> guanartee creators of plugins will not break backward compatibility
> and we cannot guarantee the non-existance of plugins with the same
> name. They belong to the app but you can share them.
>
> Massimo
>
> On Oct 21, 11:25 am, Yarko Tymciurak <resultsinsoftw...@gmail.com>
> wrote:
> > On Wed, Oct 21, 2009 at 11:16 AM, mr.freeze <nat...@freezable.com>
> wrote:
> >
> > > I like how the plugin system is shaping up but have one question about
> > > the folder structure. It seems more manageable to structure it like
> > > this:
> >
> > > applications
> > > -- my app
> > > ---- models
> > > ---- views
> > > ---- controllers
> > > ---- plugins
> > > ------ myplugin
> > > -------- models
> > > -------- views
> > > -------- controllers
> >
> > > This way a plugin would basically be a sub-app, making it easier to
> > > install/uninstall/upgrade and could also have multiple models/views/
> > > controllers.  I remember some discussion about it but can't remember
> > > what the reasons against it were.
> >
> > <sarcasm flag UP>
> > ...yes, with the added benefit that you get to make copies and copies of
> > plugins into every applications that needs it, woohooo!...
> > </sarcasm>
> >
> > Seriously, folks - think about plugins in other systems.
> > Plugins need to be that - logically, I expect them to be per web2py
> > installation (not as a component within an application);
> > Logically, I also _might_ like to see them versionsed, so that pluginA
> has a
> > DEFAULT version which links to a specific version (without talking about
> the
> > mechanism for that "linking").
> >
> >
> >
> > > On Oct 21, 10:18 am, mdipierro <mdipie...@cs.depaul.edu> wrote:
> > > > The new web2py in trunk (1.68.2) also contains an improved
> > > > experimental solution for plugins.
> > > > Here is a new video about it
> >
> > > >http://www.vimeo.com/7182692
> >
> > > > It includes suggestions from various people but I am sure it still
> > > > needs a lot of work. Anyway, give it a try and let us know what else
> > > > would you expect from a plugin system.
> >
> > > > The interface for uploading/downloading plugins is missing, among
> > > > other things.
> >
> > > > Massimo
> >
>

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"web2py-users" group.
To post to this group, send email to web2py@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
-~----------~----~----~----~------~----~------~--~---

Reply via email to