Personally, my more general concern was how to control which resources are available to plugins. I use web2py at work everyday in a true 'enterprise' setting. It is wired to several mission critical databases. The table schemas cannot be altered by plugins. These databases are separate from auth databases also. So my hope was for us to come up with a convention to hand off resources to specific plugins.
This isn't a security measure as DAL instances are global and can be accessed easily. It's more a convention of how to provide named objects to plugins, which is currently not supported. Also, it will define how a well-behaved plugin should work. I got sleepy at the end but I think Massimo and Thadeus landed on some good ideas with the help of everyone in the chat. I'm looking forward to converting all of my modules and widget into plugins. On Mar 11, 9:02 pm, Alex Fanjul <[email protected]> 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. > [email protected] -- 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.
