Yarko,
I agree, hacking is bad, hacking leads to unmaintainable code except by
those who wrote it (if then). Hacking around a current system leads to low
quality software in the end, hacking leads to either projects being
abandoned by their users, or required rewrites which waste time.
I dislike it when a system is not changed to be what would perfectly suite,
but hacked together to fit into the mold of the existing system (govt
anybody?)
And since plugins are not in web2py yet, we have no backwards compatibility
to break, lets do this right.
I really agree that the design of plugins NEEDS to be modular, logically AND
physically.
Mr. Freezes suggestion is the best layout I have seen so far, and what is
the problem with scanning the plugins folder?
This does not make web2py more clunky, it makes web2py more structured.
Only look for a plugin when LOAD() is reached. If it is found, great load
it. If not, raise an exception.
There is no reason to load the plugins every time a page loads unless their
used on that page, makes them light.
Admin would be the only place web2py would have to "auto discover" what is
in the "plugins" directory, and even it, its just a listing the folder names
in the plugins subfolder.
-Thadeus
On Wed, Oct 21, 2009 at 2:33 PM, Yarko Tymciurak <
resultsinsoftw...@gmail.com> wrote:
> 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
-~----------~----~----~----~------~----~------~--~---
