>> Who was the guy that asked the first question? One of the lead
>> developers of Django I assume?
>
> I'm guessing James Tauber? Of cloud27/Pinax fame? Definitely trying to
> "picking holes", IMO (although he chose straw men - he could have
> picked some serious holes!).
James is correct, but it was Bennet not Tauber. ;)
>> Mark, how did they know to ask you? I mean it was a great choice---
>> but a weird one. Or did you volunteer?
>
> I agreed, it was an inspired choice.
As I mentioned you'll have to thank Jacob for that one -- he's the one
who asked me to do it, and encouraged me not to pull my punches, but
to say what I really thought.
> You said exactly what I had been thinking (plus some!), with
> conviction and authority, without unnecessary antagonism. Brilliant. I
> had conversations with Jacob KM about exactly the things you talked
> about (e.g. WSGI<->Django middleware wrapper), and they are thinking
> of doing this, I think largely as a result of your talk. He confessed
> embarrassment as an engineer about the dependency graph, and was
> interested to learn more about how TG has handled easy_install (he
> didn't know you can supply your own egg repo via a html page).
Kevin Teague has a great blog post abut the package installation
infrastructure that's available in python. He pretty much charts all
the options.
http://www.bud.ca/blog/pony
Though I do think it might be worth mentioning in the context of
Django that you could do something like distribute a tarball with all
of the packages django needs included and a paver script that lets you
install all the django dependencies before you install django itself.
> Two things I learned that Django does better than TG/Pylons, IMO:
>
> Style:
>
> Django stuff looks good. The culture in Django is more design
> orientated than TG, and I think that is a factor in their success. At
> PyCon UK, Stephen Emslie demo'd a nice interactive WSGI profiler
> module[1], and one the Django folk's comments was "Sweet! But you
> Pylons guys always make things so ugly - get a designer to give you a
> style sheet already". They have a point IMHO.
Well, we need to attract more designers ;) But seriously, this is a
point well taken, and we're trying to improve the out of the box
design experience for many TG related projects. And in the
particular case of the WSGI profiler, I think that Armin may be
getting involved, and he has some design sense.
> Apps:
>
> Django has a large amount of plugin apps
> (wiki/forums/openid/tagging/notifications/IM/IRC/etc) that add
> functionality to the whole stack (views, controllers, middleware,
> model). They can do this because they know the whole stack in advance.
> The included admin interface is a classic example.
>
> Pylons doesn't dictate the whole stack, so its more difficult for
> people to write plugin apps that need top-to-bottom access. However,
> TG does make some choices, which might enable us to do more plugins
> apps, but we still value choice.
>
> RUM is likely the way forward here - if we write things to the RUM
> Factory apis[2], controller/model interactions can be abstracted to
> allow plugin apps to work with any stack component, in theory.
One that TurboGears exists, is that we want to allow people to write
plugin apps that assume the existence of SQLAlchemy, can be mounted
easily by instantiating an object, and can assume that you have other
necessary components like Beaker sessions, automatic cross-database
transactions, genshi, mako and/or jinja.
I think it would be interesting to create some of those plugins
towards the RUM data abstraction layer, but I don't at all think it's
necessary for most pluggable apps -- a very large majority of our
users are going to be using SQLAlchemy. And if they aren't we can
still use SA in plugins and have the transaction manager manage the
interactions between the plugin database commits and the ones that the
app does itself.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"TurboGears" 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?hl=en
-~----------~----~----~----~------~----~------~--~---
