Just to clarify it:Do we able to conservate my app (rewrited/extended) auth module/model, working alongside "superAuth" thadeus plugin, discarding your framework plugin and system Auth default one?
Alex
El 12/03/2010 15:31, Alex Fanjul escribió:
Ok Massimo, I agree with you in it makes no sense to rewrite a lot of web2py code.Apart from that argument in favor, there is another I don't know if it would be satisfied right now with plugin_name.py convention:-Imagine you write a *framework level plugin* to subsitute auths (or whatever system feature) views/controllers/models. -Imagine thadeusb write another *application level plugin* to do the same called "superAuth" -Imagine I write an application with an *only modules* extended auth service with some more fields and stuffs.Do we able to conservate my app rewrited/extended auth module/model over "superAuth" thadeus plugin, discarting system default one?Just thoughts, Alex El 12/03/2010 14:01, mdipierro escribió:The location of plugins is not a backward compatibility issue. From that point of view, we could relocate plugin files. The reason I do not want to do is that it is an implementation issue that requires rewriting a lot of web2py code (particularly for the bytecode-compile functionality), that will make web2py slower, not faster, and does not seem to add any new feature (except the relocation itself). The only argument I have heard in favor of relocation is in fact that code will look cleaner with a new plugins location. I do not disagree but to users of admin things will look exactly the same (because of the logical location according to admin is already the one you suggest), to users of the shell models would be scattered and it would be more difficult to identify order of execution, and you will get a little bit of cleanness is user code at the expense of lots of dirt in web2py code (lots of if statements to find out what is where). I will not do it. If somebody wants to write a fully working proof of concept implementation to demonstrate that 1) it is not slower; 2) it can be done without too much extra complexity in web2py source, I may take the patch. Massimo On Mar 12, 4:39 am, Alex Fanjul<alex.fan...@gmail.com> wrote: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*.pyweb2py/applications/my_app/plugins/my_plugin/controllers/controllers*.pyweb2py/applications/my_app/plugins/my_plugin/static/statics*.jpg*Framework Level (example: plugin for ckeditor Editor, or last Wes Jamescoda helper)* web2py/plugins/my_plugin/controllers/controllers*.py web2py/plugins/my_plugin/views/views*.pyThe 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 andwhat 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 onlyONE database (maybe clustered, spreaded, mirrored, etc. but ONE), and many of them has very complex plugins systems. The "problem" here, isthat 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 bevery 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...asumminga 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 canoverride/extend parents functionality/skins/models like the greatkohana's plugin system (someone mentioned) is the best way to achive a "easy" and "comprensible" plugin system. Yes, that would suppose a bigchange 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 evenmore powerful python web framework with new DAL, new Plugin System, newCache 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.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.
