On 1/25/07, Alberto Valverde <[EMAIL PROTECTED]> wrote: > Hi all, > > I was planning to write something soon to share what my thoughts have > been recently regarding TG's future but been very busy with paid work > (and will be until late february). Anyway, here is an update to bring > up some discussion and maybe clear some uncertainties. > > After thinking about it, meditating the past thread regarding this > same issue, reading some blogs/wikis and experimenting, I think TG > 1.1 (yep, 1.1) could start migrating to CherryPy 3 and a PasteDeploy > style configuration file for deployment. that will be good CP will bring a lot of speed, as for paste it's great since the current deploy system is very complex, specially went people forget to move their *.cfg files. can we explore the possibility of having only one config file? most of dev/prod is just duplicated from one to the other. I was thinking of having a common section which will be the ones being [foo] and then have subsections like [foo.dev] and [foo.prod].
also does this means ConfigObj is out of the package? > > Some of my confusion regarding CP3 was to the fact that I wanted it > to do something it was not designed to do: that is, make CP > applications (those composed of a RootController which mount other > controllers as attributes, etc) being able to dispatch to another > WSGI app. Although it is possible, there is a problem if the > downstream app turns out to be a CP3 wsgi-wrapped app because it will > smash cp's globals being set by the upstream app and might cause > unintended consequences. So yes, this means TG controllers will not > be WSGI callables per-se like I announced in the IRC chat on Jan 3rd :( > honestly I never liked this a lot, what use is a single controller? and since you can mount "two CP apps" together in case you need that each controller is an app in itself you just need to package them as if and you'll get the same result. > Attached is a little diagram of how I' envisioning a TG > 1.0.x app > I think that is the best, we can mix CP with plain WSGI app in the same site but it won't let all kinds of weird setups with apps inside apps inside apps that will create a nice set of easy to track bugs. > the *developer* with a cp.Tree or a paste URLMapper inside the app > factory so those apps can be encapsulated as a single app to the eyes > of a deployer/user. > umm so that means TG core will handle both cp.Tree and URLMapper? in this case will tree be the default? what are exactly the differences between them? > That whole "bunch" could be then deployed side by side other apps > easily by an *user*. > > So here is my proposed plan for action in chronological order: > > 0) Backport the 1.0 widgets back into the trunk. The widgets in the > trunk are *broken* by my early genshi integration experiments. We > have two choices: introducing ToscaWidgets into 1.1 (will break most > 1.0 apps) this will be great for many reasons, #1 no need to "waste" time making the current widgets work, #2 will finally eliminate kid from TG which is our biggest bottleneck (speed wise) #3 we'll need to write documentation for both widgets with the biggest disadvantage that most people don't understand their internals enough to make it. #4 will give ToscaWidgets a bigger exposure which will bring bug reports and (I hope) fixes making the package more mature #5 it's the right step in splitting everything up. this will be bad because #1 it makes genshi the default, as you said breaking a lot of stuff, #2 TW may not be ready for massive usage and we (read: you) may get inundated with bugs, #3 that's too many changes for a minor release. > or porting the 1.0 widgets which are working fine ATM > (albeit its design limitations). > for this of course some of the above apply, but it has a couple more cons, #1 docs for widgets will need to be written "twice". #2 people won't want to work on them (bugs and docs) because "they are going away", although bugs will be fixed by those that are affected by them. #3 it will give yet another point where TG community is divided (in a good way), and every issue on the mailing list or IRC will be replied with "TW or TGW"? > This means widgets could only use Kid for their templates and > genshi's ET should be used to display widgets in Genshi templates. > Maybe the "ET" step can be automated but I'm not very sure as it must > only occur when displaying on a page template and 1.0 widget's don't > know whether they are being displayed in a page template or inside > another widget. > again we should try to get out of kid, specially because this is the simplest port (just change 2 functions) with the biggest gain (huge performance boost) the only real problem here is the <? python ?> which many people like (I hate it) but that seems to be under good way http://genshi.edgewall.org/ticket/84, just for looking at that it seems that patch "3" and on are "almost ready" after this is applied maybe we could depend on the svn genshi until 0.4 is released. > All current TG unittests should pass before moving on to 1) User apps > should not notice this change. I assume your still talking about the second option. if not this doesn't seems possible. they will because of the <?python?> also master.kid will have to change and of course all the templates be renamed. >I believe someone who knows well CP3 and is > willing to take a look at how TG's trunk is incompatible could be of > *great* help in this area (hint, hint... ;) just leaving this so someone will read it again :) > User apps > that use filters should be adapted to use tools instead. > Documentation for this must be written. I believe this is good enough, specially since code that only calls them just needs to do find and replace http://www.cherrypy.org/wiki/UpgradeTo30#HooksreplaceFilters > > 2) Add to the resulting quickstart template a module with an > app_factory that builds a WSGI app out of the CP Root controller > loading it's TG style configuration file and merging it with a > *possible* paste.deploy config. This factory will sort-of replace > start-myapp.py I like this. > > What I mean by "possible" is that a single TG app doesn't really need > a paste.deploy config file and the CP configfile, built by the > developer, we're used to is enough. A paste.deploy config is needed > when a TG app distributed as an egg wants to be mounted side by side > in a bigger site. that sounds like too many config files, I believe we need to think this better, they are all dict based files. I see 3 possible solutions a) handle then totally separated backed by docs, howto write a paste.deploy config file, howto .... b) Do some python-foo to build the config files automagically, c) have one BIG config file with all the options and do less python-foo to build the separated ones. > A a smart "tg-admin serve" command should be able > to load a single app inside an EGG and mount it at / without needing > an explicit deployment config. However, internally, "tg-admin serve" > would delegate to "paster serve" to load that EGG's app_factory entry > point. just like all the other tg-admin tools a simplier way to call the internal one. > > Some TODOs needed for 2: > > a) Some helper functions should be integrated in Turbogears to merge > the config file. Note that all server.* directives will not be needed > (and should make no effect if present) because the app will have no > knowledge of which server will be serving it. I have some > experimental code for this. not sure if this is the best way. > > b) The "tg-admin serve" command must be implemented. This means > "start-myapp.py" will be deprecated, an alias could be implemented > for backwards compatibility by making that script delegate to "tg- > admin serve". > good idea, although this will need to make the upgrade project funtion a little smarterm I believe that today it will break the code for this, although we could just ask people to delete the old one and replace it with the new one. > c) TG's startup-hooks and extension loading should be slightly > refactored so this step can be done by calling a function from the > user's app_factory. currently there are many extension on cheeseshop this needs to be handle with care. > > d) Application devs' start-myapp.py will need to be adapted for this > change, it's not hard at all, just move that logic to the app_factory. > needs to be documented. > At this point we should have achieved: > > 1) A migration to CP3. This means, apart from other goodies, that > it'll be easy to integrate, as a developer, other WSGI apps into our > app. > 2) Making TG apps encapsulable as opaque WSGI apps that can be > integrated into any bigger site. This means, user Joe could use our > app easily in his site. > 3) 1.1 apps that will look very similar to 1.0 apps to an application > developer. > I like it. > So what's left for 2.0? > > Well, once we migrate TG's trunk to CP3 and make TG app's more WSGI > friendly and composable it's time to start building TG's development > tools using TG itself as a base. and splitting stuff. > From my point of view, TG should > concentrate on building development tools which allow for a Rapid > Development Experience (wow, new buzzword ;) This is, CRUD generator, > admin interface, model designer, etc...This means (not in > chronological order): > > - CatWalk could be migrated/reimplemented into a TG 1.1 app, > hopefully adding support for SA and being reusable in other > frameworks/apps (as it would be a standalone WSGI app with a nice > paste.app_factory entry point) and removed from TG's core. > I'm affaid to say CatWalk is very hard to migrated this will be almost a write from scratch, it is way to couple with SO idioms. what about FastData? will this die? > - ToscaWidgets can be introduced as TG would support it's preferred > way of interfacing the framework, that is with a HostFramework object > being initialized on every request by a piece of middleware. (If you > ask, TW integrates into 1.0 without it's middleware...) > ok I need to read on that. > - Identity could be replaced by two layers of middleware which > handled authentication (AuthKit sounds like a nice candidate), and > authorization (a refactored TurboPeakSecurity that is being gestated > which will emulate Identity's authorization API but being generic > functions in under the hood allowing any sort of crazy authorization > policies) > my only problem with this is the generic package itself, it's a great concept but we are depending on Phillip's limited time. http://www.eby-sarna.com/pipermail/peak/2007-January/002660.html > - Decorators can be simplified and made less magical/complex... I > already have some ideas experiments for this... > > - We can start investigating/stealing useful tools from other > projects.... (I18NToolbox, Pylons version of EvalException, > HTTPEncode, etc, etc...) comments on this two for later. > Free beer? where do I send it? --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears Trunk" 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/turbogears-trunk?hl=en -~----------~----~----~----~------~----~------~--~---
