Hi Massimo,
I haven't said that plugins should have to depend on others, but they
should be able to access/play with others to make a trully plugins
central network, the dependencies are resoluble at highly level with an
exposed convention API like:
plugin_most_active_users.requires=['comments-1.x.x', 'auth-2.x.x']
plugins['tag_cloud'].requires =['tags-1.2.x']
Its only an idea.
The backward compatibility breaks with the heritance folder structure
(as I though you said), isn't it?
*App Level: (example: plugin for commets)*
web2py/applications/my_app/plugins/my_plugin/modules/module*.py
web2py/applications/my_app/plugins/my_plugin/views/views*.py
web2py/applications/my_app/plugins/my_plugin/controllers/controllers*.py
web2py/applications/my_app/plugins/my_plugin/static/statics*.jpg
*Framework Level (example: plugin for ckeditor Editor, or last Wes James
coda helper)*
web2py/plugins/my_plugin/controllers/controllers*.py
web2py/plugins/my_plugin/views/views*.py
The way to ordering load is down-to-up I think, like kohana does:
http://docs.kohanaphp.com/general/modules,
http://v3.kohanaphp.com/guide/about.filesystem.
Also it's very important the hooks
<http://docs.kohanaphp.com/general/events> & events
<http://docs.kohanaphp.com/general/events> system, as both of you
(thadeus, Massimo) talked at the end of the chat:
There is no calling for new Cache system at all...just was an example...
regards,
Alex
El 12/03/2010 5:26, mdipierro escribió:
I agree with most of what you say.
99.99% of apps use a single database and so will plugins. This is
because they needs auth to do anything meaningful.
I do not think it is a good idea to have plugins that depend on each
other. dependencies are a mess to manage. In any language and any OS I
ever used. plugins with dependencies are cause for trouble.
But I agree that we may build groups of plugins that cooperate for
some specific tasks (like share access to certain tables and or
certain web services). This will happen for plugins geared toward
specific types of apps so we should not over-engineer it now.
I do not think we need a 2.0 for those things that you asked. We will
get there in small steps and, at this point, I do not see why any of
those improvements should be inconsistent with backward compatibility.
What's your wish list for cache? I never heard anybody calling for a
new cache system.
Massimo
On Mar 11, 9:02 pm, Alex Fanjul<alex.fan...@gmail.com> wrote:
Very interesting and constructive IRC meeting, congrats to all. After
reading all text I have some comments:
- Most of the meeting (50% at least) was concerning about *how many and
what databases should plugins have access to*...it seems the most
headache for all, BUT, I'm pretty sure that 99% of today real WEB
applications (and very complex ones) in world uses no more than 1
database: think of Magento's, Elgg's, Zimbra's, Active Collab's,
Twitter's, OpenBravo's, Wordpress's, Drupal's, etc. All of them use only
ONE database (maybe clustered, spreaded, mirrored, etc. but ONE), and
many of them has very complex plugins systems. The "problem" here, is
that with web2py its very simple and easy to create a new database: just
do "db=DAL(...)"... and many times we are even "confusing" (in the right
sense) databases with tables... A game for us: Tell me more than 2 real
web applications using more than one database. A reflection: I would be
very afraid if after installing 20 plugins (as I have in my latest
drupal installation) I bump into 20 (or 15 or 10 or even 5) new
databases in my phpmyadmin/pgadmin. Yea: be generic and assume all
posible cases... but....
I think Thadeusb was in the right direccion in some comments...asumming
a worst case of ONE shared db for plugins. moreover this would
simplified things, right?
- "Turicas: should a plugin access other plugins' data?" --> "thadeusb:
Turicas: I would think no, because a plugin should be self contained."
In this case I disagree, the plugins -for sure- should be able to access
to other plugins data/functions, because as centralplugins grow up, many
of them will be based on others to not reinvent the wheel, so *we will
need a strong convention in exposing API for functions, objects, etc.*
(think of a "plugin_most_active_users" based on thadeus "plugin_commets").
- Finally I believe that a "heritance folder convention" where you can
override/extend parents functionality/skins/models like the great
kohana's plugin system (someone mentioned) is the best way to achive a
"easy" and "comprensible" plugin system. Yes, that would suppose a big
change and probably a backward compatible inflexion point, but as
Massimo said, talk me about functionallity not about implementation.
Concerning this, and to be honest I'm always thinking of a Massimo
annunce saying: "Web2py 2.0 Released: the new easier, faster and even
more powerful python web framework with new DAL, new Plugin System, new
Cache System, new CSS/Form system, etc. (ops but without 1.x backwark
compatibility sorry)", but it's just a dream :-P
Is there any new IRC appointment planned?
Best regards,
Alex
PD: excuse me for my english (as always)
--
Alejandro Fanjul Fdez.
alex.fan...@gmail.comwww.mhproject.org
--
Alejandro Fanjul Fdez.
alex.fan...@gmail.com
www.mhproject.org
--
You received this message because you are subscribed to the Google Groups
"web2py-users" group.
To post to this group, send email to web...@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.
