Those book cost too much.

We really need to resolve this over a beer.

is the only thing you are asking to keep plugins files under a
separate folder?

How would the plugin be able to override the layout.html?
How would it be able to overwrite a module (for example a local
customized version of simplejson)?
 modules have to be toplevel in site-packages (in our case in app/
modules).
Or consider a cms that has a file views/default/index.html. A plugin
for the CMS should be able to override that file.

Massimo

On Oct 30, 12:41 am, Yarko Tymciurak <resultsinsoftw...@gmail.com>
wrote:
> or perhaps (better) Chapter 4 
> inhttp://www.amazon.com/Principles-Design-Oxford-Advanced-Manufacturing...
>
> On Fri, Oct 30, 2009 at 12:39 AM, Yarko Tymciurak 
> <resultsinsoftw...@gmail.com> wrote:
> > see, for example, sections 1.7.5 - 1.7.6 in
> >http://www.amazon.com/Axiomatic-Design-Advances-Applications-Manufact...
>
> > On Fri, Oct 30, 2009 at 12:32 AM, Yarko Tymciurak <
> > resultsinsoftw...@gmail.com> wrote:
>
> >> On Thu, Oct 29, 2009 at 11:21 PM, mdipierro <mdipie...@cs.depaul.edu>wrote:
>
> >>> Let's say we were to create a new folder called applications/*/
> >>> plugins, put stuff in there and modify web2py to handle the code in
> >>> there in some special way. That the current mechanism in admin for
> >>> packing, unpacking, deleting would still work. It is because plugins
> >>> in a subfolder are simply more specialized plugins than the ones I am
> >>> defining.
>
> >> I don't see this at all - I talk about implementing in a cleaner way the
> >> SAME thing you are doing (no difference in behaviors, so not at all more 
> >> nor
> >> less restrictive).
>
> >> It seems to me you are just talkking about ease of implementation, because
> >> (?) you don't see value in not having the code all peppered in with 
> >> "normal"
> >> application.
>
> >> As I look at your stuff on this, if you call it components, plugins, or
> >> whatever - it's all the same - you can define how you want.
>
> >> It's just a matter of how well differentiated those component (or
> >> "application subsets", as you call them - but, really, there is no need nor
> >> benefit that I can see in defining new terms as we continue to talk about
> >> the same things;  actually, re-naming terms just for the sake of taking an
> >> argumentative position, without any functional difference as far as I can
> >> see I think is just consuming attention on non-useful things, and adds
> >> unnecessary confusion.  I would prefer to stick to one term - plug-ins - 
> >> and
> >> discuss what affects how those work, how they are written, how they can
> >> serve and be used within applcations, etc.   All the other name-changing 
> >> and
> >> implementation-details arguments get away from what I think is the
> >> "interesting" part of the discussion:  behaviors, and
> >> encapsulation/differentiation (e.g. can I just "plug in" a scheduler in an
> >> existing app, and what - if anything - do I need to get it to work?  do I
> >> need to install a scheduler - for example - plug-in once in my web2py, or 
> >> do
> >> I _have_ to install it in every app (and why?  what would be the benefit of
> >> one way or the other?).
>
> >>> Let me play with with words:
>
> >> Please - let's not;  no benefit to this as far as I can see....
>
> >>> - What I call plugins should instead be called
> >>> random_applications_subsets
>
> >> ...ach....
>
> >>> - What you call plugins are special types of
> >>> random_applications_subset that are somewhat isolated.
>
> >> ...ach....   yes, just call it plug-ins, and lets define those.  What
> >> motivates the change in name every time I ask about defining better what 
> >> you
> >> are conceptualizing?  No profit in this renaming, as either way the work of
> >> thinking thru, being intentional (AND appropriately flexible), and defining
> >> it CLEARLY is STILL the work at hand.   Leave any tweaking of the name to
> >> something more appropriate to later - call it a tiger AFTER is has been
> >> clearly been made into whatever kind of animal it will turn out to
> >> be!!!!!!!!!
>
> >> Ach!
>
> >>> What you call plugins does not exist yet. It needs to be created.
>
> >> .... defined, discussed, considered, and spelled out....
>
> >>> I am
> >>> taking a top-down approach instead of bottom-up approach
>
> >> No you are not - in fact, you are taking (as far as I can see) bottom up
> >> (that is "build it, then call that the specification, if you like it)
> >> approach ---- but in any case, this is a completely irrelevant discussion,
> >> as doing both top-down and bottom-up to discover what is the most useful
> >> shape is all part of the process of defining this....
>
> >> So let's focus on behaviors and use (not names, implementation details,
> >> and irrelevant development steps - top-down / bottom-up, after all, the
> >> right mix of these is what creates a result;  the result is not "top-down"
> >> or "bottom-up" --- that kind of description makes no sense in describing a
> >> behavior / result anyway!
>
> >>> because I am
> >>> afraid of building something that turn out to be too restrictive.
>
> >> Fine - then talk about what degrees of freedom you want to ensure, and
> >> this will help specify what ... does not yet seem to be crisply
> >> specified....
>
> >> What do you want to allow?   What do you want to avoid restricting?
>
> >> I (for one) want to allow adding a calendar to my app, after the app has
> >> been deployed, without needing to do anything / change anything in my app,
> >> AND without the plug-in  knowing anything about my app tables, or being 
> >> able
> >> to directly touch my app data (THAT would TRULY be restrictive, and in 
> >> other
> >> ways coupled unnecessarily, and ....  I'll leave it to you to read all the
> >> mathematical treatments of design coupling separately - e.g. Nham Suh's
> >> treatmeint in "Axiomatic Design"...  there are others, but that is a pretty
> >> good description (even if it is gererally a weak guide to design).
>
> >>> When
> >>> we have in trunk is a convention.
>
> >> Actually, it is very little more than that, and it seems grossly
> >> under-defined (perhaps even "dangerously" so, in the sense that it allows
> >> too many degrees of freedom, too many opportunities for coupling, too many
> >> ways for it to become highly restrictive and decay into something not
> >> useable).   This is why I keep driving for better work on this;   perhaps I
> >> should just go off and write a few chapters to show examples of how to
> >> design this, but I would not attend to that for many months, so instead I
> >> try to encourage a little more to happen here.....
>
> >>> We can decide tomorrow not to follow
> >>> it any more and remove the page in admin and no application would
> >>> break. This is the beginning of a story that is yet to be written.
>
> >> Yes, and a dialog of pertinent discussions will help form the "story"
> >> (e.g. the general architecture, shape that will be useful and sustainable
> >> and flexible).
>
> >>> Before we write it we need to learn what others have done (Drupal for
> >>> example).
>
> >> I found little useful in that architecture (other than defining an
> >> interface for plugins to implement, and details of what is needed to
> >> accomplish that in PHP - we need to just start w/ Python, and how to make
> >> that work in web2py app structure...
>
> >>> I do not want to create a single plugin system (I do not believe in a
> >>> one size fits all solution here)
>
> >> It seems to me your are mixing two different discussions here.  It would
> >> be good to separate them, or the discussion will necessarily be eternally
> >> circular:
>
> >> - An abstraction that leads to a design / architecture (e.g. structure and
> >> standard interfaces, and basic install / discover "conventions")  is a
> >> USEFUL  "one size fits most" for a class of problems - this is, after all,
> >> what architecture sets out to accomplish in ALL software engineering.
>
> >> - A PLUGIN is where the solutions (and the variability you desire, and the
> >> "one size doesn't fit all" argument belongs) are designed.  Not ALL
> >> solutions will be appropriate to the "shape" of a plugin, but many - enough
> >> that it is USEFUL to consider what shape will serve this class of solutions
> >> well (that is, what architecture and conventions we "want" for a plugin
> >> system)
>
> >>> but I want to give people like you
> >>> the ability to create their own plugin system.
>
> >> *sigh*   Well, there is a saying - the "great" thing about standards is
> >> there are so many to choose from.
>
> >> Stated more clearely (since that is a rather sarcastic statement) - too
> >> many standards errode the benefit of having ANY standard.
>
> >> A plugin system by which web2py authors can easily share (and "plug in")
> >> pieces of solutions is desireable.
>
> >> It seems you need to make a decision:   define a generally useful plugin
> >> system for the community to accomplish this, which leaves appropriate
> >> flexibility to maximize the range of solutions that this will be capable of
> >> accomodating  (or leave it to others to define, even if that might risk
> >> resulting in "many standards to choose from" for web2py application and
> >> plugin authors).
>
> >>> Some plugins may be
> >>> specialized for a particular web2py CMS or other type of specialized
> >>> type of app.
>
> >> Again - please PLEASE keep seaparate the particular plugin ("some
> >> plugins") from the plugin system to hold / deploy / use those plugins
> >> through.
>
> >> We have gone around and around on this discussion in circular, and mixed
> >> discussions (e.g. implementation details;  mixing the system from the 
> >> "range
> >> of plugins", e.g. flexibility - these are separate concerns around the same
> >> class of problems).
>
> >> Perhaps this really is beyond this kind of email discussion, where the
> >> separation of concerns and considerations (and tasks) is not so clear to
> >> everyone.
>
> >> Unnecessary coupling is "evil" and reduces flexibility, and getting to see
> >> where it exists is much easier when concerns are separated, since a more
> >> focused view appears as a result.
>
> >>> Now I am going to redefine:
>
> >>> plugin_0 := random_application_subset
> >>> plugin_2 := what Mr Freeze calls a plugin
> >>> plugin_3 := what Alvaro calls a plugin
> >>> plugin_N := what Yarko calls a plugin
>
> >>> where _i indicates a higher level of abstraction/encapsulation of
> >>> functionality.
>
> >> I see NO functional distinction between these - if you INSIST on this
> >> proliferation of names ("this one is cheese;  this one is swiss; this one
> >> goes on a sandwich;  this one goes on salad; provolone is for pasta;")
> >> then I must ask - is there any PERTINENT and important distinction between
> >> these, as far as discussion of the system for inserting / activating / 
> >> using
> >> these is concerned?
>
> >> So far, I see NO need for distinction, rather a discussion of what is
> >> COMMON among these, and what does that tell us that a plugin system - OUR
> >> plugin system should need?
>
> >>> plugin_0 is simple. It is done. It is just a
> >>> random_application_subset. The thing being plugged (plug) is a bunch
> >>> of files. The thing it plugs into (socket) is an existing application,
> >>> and it may very well break if socket and plug are not compatible.
>
> >> This is nothing more than code that is part of the application, and (if I
> >> recall) it may be COUPLED in the application.   There is little that speaks
> >> of or attempts to enforce / encourage encapsulation - I would not even call
> >> this a plugin;  I see no real utility in this.
>
> >>> plugin_{i>0} are more complex because we need to define more clearly
> >>> types of plugs and sockets.
>
> >> This is where discussion of the following sorts are appropriate and
> >> necessary:
> >> - SHOULD the plugin be able to modify application tables directly?
> >> (NO!!!)
> >> - HOW can the application DISCOVER the plugin?
> >> - HOW will the plugin and application interact?  (Thru plugin interfaces
> >> that the plugin may optionally define?  What do those need to be?  How
> >> flexible can they be?   What are the REQUIRED implementations, e.g.
> >> discovery and interface publication?)
> >> - HOW will the plugins be installed, and instantiated (with gluon?  what
> >> is consequence of this?  with requst, per app?  with app instantiation?  
> >> How
> >> should discovery work in each case?)
> >> - Shall a plugin be PER web2py?   PER  application?  Both options?  What
> >> are the benefits of each?
> >> - How shall VERSIONS of plugin modules be dealt with?  Can an application
> >> require / restrain a version?  (How can this be implemented?)
>
> >>> I am thinking about functions that need to
> >>> dynamically create tables, insert records, change layout, add cron
> >>> jobs, add internationalization strings, generate js, pieces of the app
> >>> that need to communicate client-server, server-server, client-client
> >>> (same client or different client).
>
> >>> I think this is going to take time.
>
> >> Agree....  For the questions I've suggested above where the answer is "Gee
> >> - I am not sure, or I don't know" - a bottom-up (e.g. prototype it to find
> >> out!) approach is appropriate.
>
> >>> Drupal provides a limited but
> >>> successful approach that can help kick off a more concrete discussion.
>
> >> I looked at the Drupal docs today, and am not sure there is so much that
> >> will be of help there;  you may have a different conclusion.
>
> >> - Yarko
>
>
--~--~---------~--~----~------------~-------~--~----~
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