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
-~----------~----~----~----~------~----~------~--~---
