On Fri, Oct 30, 2009 at 1:12 AM, mdipierro <[email protected]> wrote:
>
> Those book cost too much.
>
... and probably not generally so useful; Nam (I think) was a friend of
Reinke's/Baskin's (who wrote the paper on Role of Finiteness in Emergence of
Structure).... Suh was (is?) head of Mechanical Eng. @ MIT; we discussed
many times (and I perhaps most vociferously) Suh's approach. Yet, I don't
think I've ever seen a better treatement and description of the effects of
coupling (as related to functional requirements and design parameters).
I will surely have reference to this bit of material in my design writings /
book.
>
> We really need to resolve this over a beer.
>
As long as you are buying, I am willing to talk thru this ;-)
>
> is the only thing you are asking to keep plugins files under a
> separate folder?
>
No - that is but the most shallow of interpretations of my concerns.
For Suh, he talkes about FR/DP as a component of this. The
Reinke/Baskin/Mittenthal equivalent is "nature of problem" (FR), versus
"nature of solution" (DP). Folder is but one, and but the simplest, least
far reaching of possible DP's for what I am talking about.
The full P-A-D-i aspect of this, folders are but an incomplete example of
the "i" aspect of what I am talking about.
>
> How would the plugin be able to override the layout.html?
>
In the case of the Drupal plugin system, PHP blurs MVC separation - so that
is not a good analogy / system for thinking about this.
I think we need a completely separate handling / plugin system for "skins"
and layout / the "V" of MVC.
I think functional ("controller" or MC) plugin system will need to be
started out separately considered. There may be a good part of common
ground, but I have trouble (with static folders, CSS, etc.) seeing how these
can usefully be thought of as the same kinds of plugins to start with.
I think we need to start by considering them separate problem sets, and
later see how close we can make them in practice.
> How would it be able to overwrite a module (for example a local
> customized version of simplejson)?
>
Important question - override/overload (rather than over-write) I think is
perhaps the appropriate mental model to start.
I'm not sure, haven't thought about this - perhaps we can get input?
modules have to be toplevel in site-packages (in our case in app/
> modules).
>
Not sure I see this - that they "have" to be.... but say more about why you
think that....
> Or consider a cms that has a file views/default/index.html. A plugin
> for the CMS should be able to override that file.
>
.... and a special case (e.g. a manager) context should be able to override
the "default" CMS override (this is where I think "application loaded"
plugin behavior comes in - like adding a validator to a table at runtime,
only in a context, so logic should have the ability to load an alternate
plugin behavior in a situation).
I am fairly (intuintively) convinced that all 3 levels of plugin action I
have laid out will be similtaneously useful - gluon / site level (e.g. how
you would install a particular authentication plugin), all application
availability (e.g. calendar / scheduling plugin), application level (e.g.
specific, or customized, or version specific, per request behavior for an
application), as well as application "loaded" (logic / context modified, as
I mentioned earlier here).
I don't think this is a matter of "which do we want" but rather a case of
"we really need a plugin system that enables all / any of these" so that a
site and / or application can take advantage of "a plugin" as it needs.
>
> Massimo
>
- Yarko
> On Oct 30, 12:41 am, Yarko Tymciurak <[email protected]>
> 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 <
> [email protected]> 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 <
> > > [email protected]> wrote:
> >
> > >> On Thu, Oct 29, 2009 at 11:21 PM, mdipierro <[email protected]
> >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 [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/web2py?hl=en
-~----------~----~----~----~------~----~------~--~---
