Achipa I agree with your logic about rewrite 100% but that is why I was suggesting applying any new approach to Auth as that is not yet set in concrete.
I think your comments re maximizing development pace for a give amount of effort are really interesting. Tho' it does remind me of the story about the guy who jumped from a skyscraper and as he went past the 13th floor said "so far so good". Bill On Jan 23, 12:05 am, achipa <[email protected]> wrote: > We're still shoveling a lot of terminology at each other while mostly > agreeing on things esp with regard to plugins. If left to my own > devices, I'd put in something into __init__.py in the application > folder and/or name the folder itself plugin_[pluginname] so it's clear > both visually and programmatically who/what's a plugin and who/what > isn't. I don't have a problem with applications being plugins (or was > it rather the other way round :) ). Local versions of plugins (=per > application) are IMHO a mess no matter how you do it. > > As for billf's comments, I mostly agree, but I don't see this being > done without a) going v2.0 and b) having a goal, yes, clean is cool, > but don't rewrite code just because you're smarter after you've > written it. Sure enough, my engineering sense tells me that rewrites > that make stuff cleaner are good, but from experience, unless you have > a reason to rewrite with regard to the future, that time is better > spent on more pressing/common issues (I sincerely hope people > understand what I'm saying here, it's not about (non-)messy code, but > rather how to maximize development pace for a given 'amount' of > effort). > > On Jan 21, 10:47 pm, mdipierro <[email protected]> wrote: > > > no. I can use help in "inventing" them. > > > Massimo > > > On Jan 21, 3:45 pm, billf <[email protected]> wrote:> What is > > aPLUGINfile and do any exist already? > > > > On Jan 21, 6:05 pm, mdipierro <[email protected]> wrote: > > > > > > * I think that the very fact that you can take parts of T2 and > > > > > incorporate them in the core proves that apluginis not necessarily > > > > > an app (in the recognised sense of the word). If Auth is replaceable > > > > > by aplugin, it is (or may as well be) apluginitself. The key > > > > > element is how thatpluginis integrated. In the case of Auth, I > > > > > seems it must be via Crud (I could be wrong) but Crud enforces a URL > > > > > format which surely can't be mandatory to handle authorisation. > > > > > Stuff is moved into core only if can be done in a module without > > > > services, static files and without mandating conventions on how to > > > > expose them. Nevertheless Auth and Crud do provide a "simple" and > > > > "naive" way to expose themselves until the developer figures out how > > > > that can be customized (I will document it eventually). > > > > > > * you say apluginis an app and "does not deserve a special folder > > > > > butpluginapps need to identify themselves. I think aPLUGINfile in > > > > > the app folder should do the task." But in the previous sentence you > > > > > say aplugin" can have modules, models, controllers, views, static > > > > > files, services." That is contradictory isn't it. > > > > > No. thepluginis an app (which already contains modules, static, > > > > etc.) > > > > thePLUGINfile is needed to describe via some metadata or text how > > > > this app exposes services that other apps can use. Thus making it a > > > > spacial app, thepluginthat is. > > > > > > * Neither of the above apply to Auth which doesn't have a lot of other > > > > > files but isnt in an "app folder" either. > > > > > The way I am implmenting it does not need to be an app. But class > > > > CasAuth(Auth):pass needs to be an app because exposes CAS provider > > > > services. > > > > > > * when you say "in the app folder" do you mean "applications" folder > > > > > or the same folder as the app? (I'm assuming the latter) So every > > > > > app that requires Auth must have it's own copy of theplugin? I'm not > > > > > sure whether that is good/bad. > > > > > Every application that requires Auth will just need web2py and do from > > > > gluon.utils import Auth! > > > > If an app needs apluginthat extends Auth by providing for example > > > > CAS would need theplugin(as they need CAS now). > > > > > It has. It just has not been explained properly perhaps. It is also > > > > true that different people expect different things from a "plugin". > > > > For me a "plugin" is defined as an "app" that provides modules, > > > > services, views and static files, that can be used by other apps. This > > > > means I do not want specifications to be too strict. If you are > > > > expecting more from it perhaps you should explain what you would like. > > > > > Massimo > > > > > > I'm sorry, it just seems the thing hasn't been thought thru. > > > > > > On Jan 21, 4:09 pm, mdipierro <[email protected]> wrote:> Hi > > > > > Bill, > > > > > > > I will try to answer some of the questions you raised in the thread. > > > > > > > We had an IRC meeting last week and we agreed that T2 was becoming > > > > > > common and people started to rely on it. At the same time > > > > > > maintaining > > > > > > web2py+T2+T3 as separate entities was becoming a nightmare. We > > > > > > agreed > > > > > > that it was possible to incorporate some parts of T2 (those that we > > > > > > consider good practice and those that only require python modules) > > > > > > into web2py. > > > > > > This includes: > > > > > > - Authentication > > > > > > - Role Based Authorization > > > > > > - Smarter Crud than SQLFORM provides (integration with > > > > > > authentication, > > > > > > more restful paths) > > > > > > > The current T2 would become an example on how to extend this core, > > > > > > in > > > > > > the same fashion as you suggest. > > > > > > > T3 will stay an anonymous app that based only on web2py and perhaps, > > > > > > once polished, it could be distributed with web2py in the future. > > > > > > > About the "concept" ofplugin. I agree with almost everything you say > > > > > > but let me insist: APLUGINIS AN APPLICATION. Just a special type of > > > > > > app. It can have modules, models, controllers, views, static files, > > > > > > services. It does not deserve a special folder butpluginapps need to > > > > > > identify themselves. I think aPLUGINfile in the app folder should do > > > > > > the task. > > > > > > > We do need to write API specs on how to write plugins. > > > > > > > For example. By having Auth provided now by web2py code, aplugin > > > > > > could be > > > > > > > class CasAuth(Auth): ... > > > > > > > which exposes the same APis as Auth but uses CAS. Thepluginwould > > > > > > also include a CAS provider app. > > > > > > > Massimo > > > > > > > On Jan 21, 9:19 am, billf <[email protected]> wrote: > > > > > > > > RE plugins, I think the other area that could be addressed is how > > > > > > > web2py allows certain types ofpluginto operate. > > > > > > > > For example, it would be nice if web2py says "I provide for the > > > > > > > following types of authorisation at point x, y, and z where I will > > > > > > > call a function (either called a, b and c or stored in attributes > > > > > > > d, e > > > > > > > and f)", i.e. the api that a "standard" authorisationpluginmust > > > > > > > meet. That way a) anyone writing their own know what they have to > > > > > > > provide and b) it documents what web2py must support for > > > > > > > backwards- > > > > > > > compatibility. > > > > > > > > There are probably some internal areas that might benefit from a > > > > > > > similar api document, e.g. the "api" exposed to a view, although I > > > > > > > can't quite envisage it at present. > > > > > > > > On Jan 21, 2:47 pm, billf <[email protected]> wrote: > > > > > > > > > For now, I don't know if there is a difference between module > > > > > > > > and > > > > > > > >pluginbut let's assume there is to keep it discreet. > > > > > > > > > * apluginfolder > > > > > > > > > * eachpluginis a) a file or b) a folder - latter is more > > > > > > > > flexible if > > > > > > > > more than file required > > > > > > > > > * an admin UI can display all plugins from thepluginfolder > > > > > > > > > * a means of stating dependency upon other plugins and conflict > > > > > > > > with > > > > > > > > other plugins so that the admin UI can automatically > > > > > > > > check/include/ > > > > > > > > warn - is this by lines within the main(?)pluginfile or a > > > > > > > > separate > > > > > > > > config/manifest/descriptor file > > > > > > > > > * a means of describing theplugin- in text including syntax > > > > > > > > (same > > > > > > > > points as above lines or file) > > > > > > > > > * I don't know the best way to actually import/include into app/ > > > > > > > > project - any ideas? > > > > > > > > > Bill > > > > > > > > > On Jan 21, 2:08 pm, Timothy Farrell <[email protected]> wrote: > > > > > > > > > > So the big question is...what would apluginsystem look like? > > > > > > > > > What > > > > > > > > > would you want it to control? > > > > > > > > > > Currently the T2 functionality is a set of Python methods > > > > > > > > > that you can > > > > > > > > > expose and add to your app. I agree that it looks cludgy, > > > > > > > > > but how can > > > > > > > > > it be made better? > > > > > > > > > > I want to keep things narrow in this discussion. So let's > > > > > > > > > have an > > > > > > > > > example: Authentication. Let's say I have an app and I want > > > > > > > > > to add > > > > > > > > > authentication to it (aside from Basic HTTP auth). How would > > > > > > > > > aplugin > > > > > > > > > add this functionality to my app? > > > > > > > > > > -tim > > > > > > > > > > billf wrote: > > > > > > > > > > I've been away a while so I am trying to catch up with all > > > > > > > > > > the new > > > > > > > > > > stuff. I've downloaded the version in trunk and I'm trying > > > > > > > > > > to get my > > > > > > > > > > head around it all. My first (admittedly very early) > > > > > > > > > > impressions are: > > > > > > > > > > > 1) The functionality is nice but, personally, I don't see > > > > > > > > > > utils.py > > > > > > > > > > stuff as core web2py. > > > > > > > > > > > 2) I would prefer to see a simple, well-defined, rock-solid > > > > > > > > > > core and > > > > > > > > > > everything else as aplugin. I accept that where you draw > > > > > > > > > > the line is > > > > > > > > > > totally subjective. For example , I have no problem with a > > > > > > > > > > mandatory > > > > > > > > > > 'id' and would like to see an optional > > > > > > > > > > 'last_modification_timestamp' > > > > > > > > > > included in the core. Others want neither. I have a > > > > > > > > > > problem with > > > > > > > > > > Mail, Auth and Crud in the core. I'm sure others see no > > > > > > > > > > problem. > > > > > > > > > > > 3) Someone devise a > > ... > > read more » --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "web2py Web Framework" 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 -~----------~----~----~----~------~----~------~--~---
