see, for example, sections 1.7.5 - 1.7.6 in
http://www.amazon.com/Axiomatic-Design-Advances-Applications-Manufacturing/dp/0195134664
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
-~----------~----~----~----~------~----~------~--~---
