To put this in a more constructive path - take your list of 3 objectives
(below), work out what KINDS OF THINGS they represent, and if anything
already exists that does a similar thing IN THE WEB2PY / PYTHON context.
Then look for similar kinds of things that are very close that this is like
(that is, get a central abstraction you can live with - this will be your
"definition" and all your semantic complaints will fall away).
For modularity, identify cleary how each numbered requirement would be
satisfied, and by what system actor/component (e.g. there will probably be
new ones). Assign specific responsibilities to specific parts, and keep
that de-coupled. RIght now, I can find LoadFactory().
Then talk about appropriate structure to KEEP THINGS from being either
apparently (e.g. sphagetti code entanglement) or in fact coupled, as this
will harm the fundamental goal of modularity.
THEN start brainstorming ways to approach a solution, and prototype.
Present a promising prototype to the list.
This should not be a lengthy thing, maybe a weeks of work / time, a few
IRCs.
As it is, I have a hard time thinking about this structure, much less
knowing what is doing what... or what to expect of it...
On Wed, Oct 21, 2009 at 1:42 PM, mdipierro <mdipie...@cs.depaul.edu> wrote:
>
> Every time we discuss this we spend time on semantic issues and I
> would rather not enter into this discussion.
>
> What I want:
>
> 1) ability to built applications in a more modular fashion ({{=LOAD
> ()}} provides that)
> 2) ability to take a piece of an app out and reuse in another app (the
> "plugin_" prefix and some conventions could allow this)
> 3) the ability for some special types of app (CMS) to auto-discover
> certain special types of plugins (like in Drupal) and change
> accordingly (we do not have this yet because I am not sure what the
> requirements are).
>
> The purpose of a plugin, as I intend it, is not to replace the concept
> of python modules (i.e. pieces of codes that you import once and are
> available everywhere), it is not to create a new new complex system of
> dependencies between web2py objects (which would be nightmare), and it
> is not to create a new mechanism for installing/uninstalling
> applications (or pieces of an application). This means an app can
> depend on a plugin but plugins should not depend on each other, a
> plugin can be designed for a specific class of apps.
>
> My goal is always to simplify the "web2py experience" not make it more
> complex.
>
> Massimo
>
> On Oct 21, 1:18 pm, Yarko Tymciurak <resultsinsoftw...@gmail.com>
> wrote:
> > On Wed, Oct 21, 2009 at 1:14 PM, Alex Fanjul <alex.fan...@gmail.com>
> wrote:
> > > I think that the best cms "framework" for take a sight in it is
> Drupal
> > > and his great plugin system...
> > > It has core plugins and optional (downloadable plugins). Firefox is not
> > > comparable because all of them are "optional" type,
> >
> > I respectfully state that this is the difference between a component (not
> > optional, part of a build) and a "plugin" (plug in ==> insert or
> remove).
> >
> > > you can not choose if you want to use gecko engine (for example)
> > > It would be great to have a "web2py-centraplugin.com" to download or
> find
> > > all of them...
> >
> > > alex f
> >
> > > El 21/10/2009 20:03, Yarko Tymciurak escribió:
> >
> > > 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
> >
> > > --
> > > 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 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
-~----------~----~----~----~------~----~------~--~---
