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.
>
Semantics would be about different meanings for the same / similar terms;
The problem here is not semantics, but fuzzy definition - use of a term that
has different meaning than apparent use.
>
> What I want:
>
> 1) ability to built applications in a more modular fashion ({{=LOAD
> ()}} provides that)
>
That's fine - dynamic loading is but one way to accomplish this, and I hear
you value that.
This - however - is incongruent with "each app should distribute it's
plugins" - that is simply tangential, and (worse in my view) a sign of
completely unnecessary coupling, and appears contradictory to "modular"
desire.
(Meaning - not semantics)
2) ability to take a piece of an app out and reuse in another app (the
> "plugin_" prefix and some conventions could allow this)
>
First - the PREFIX method is ... archaic, and creates a interweaving of
source (spaghetti!) with an existing app. It feels messy, and the only
thing I heard arguing for it is that you understand how to implement this.
It LOOKS LIKE design coupling (intermixing code with unrelated, supposedly
modularly distinct code) - bad idea in my book.
That you are calling for tools to install and uninstall this coupled weave
is a red flag; that, because the code is editable, such tools are likely to
be fragile is also a bad indicator.
These are all signs that this design needs more thinking, is not ready.
> 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).
>
Fine - still more need for definition (e.g. requirements, and clarity of
meanings).
>
> 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.
>
All of this, and your correct observation that we get into discussions of
meaning (not at all semantics) is a sign that this design work is not done.
Every time I see this, I shudder, and ask "what are you doing?"
I would suggest to throw all the hacking out, and start with what you want
(forget about arbitrary "app must distribute plugin" - that too is but an
artifact for incompletely thought out design, as if discovery where there,
then auto-loading, ala shared library concept would be possible, and all
that would be needed is a specification of what plugin should be in the
system, and a graceful behavior set in the lack of presence of that.
*sigh*
- Yarko
>
> 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
-~----------~----~----~----~------~----~------~--~---
