or perhaps (better) Chapter 4 in http://www.amazon.com/Principles-Design-Oxford-Advanced-Manufacturing/dp/0195043456/
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-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 -~----------~----~----~----~------~----~------~--~---
