Ticket #216

[Peter Hunt]

Thoughts? I am in support of it.

Peter Hunt

[Lethalman]

Only with these options:
1) Controllers as the subway way (not classes)
2) Cheetah and not kid
3) Other subway features

Or even let the user choose what components to use. The web app should
then support as many items as it can, providing an abstract layer for
each of them. For example
- FormEncode/Atocha
- Cheetah/Kid
- Class controllers/Filesystem controllers
- and so on...

Another thing... the tg administration interfaces (like catwalk and
i18n) must be closed for now until products are in.

On 12/17/05, Peter Hunt <floyd...@gmail.com> wrote:
> Thoughts? I am in support of it.
>
> Peter Hunt
>

--
www.italianpug.org - Italian Python User Group Founder
www.lethalman.net - Thoughts about computer technologies

[Alia Khouri]

Peter Hunt wrote:
> Thoughts? I am in support of it.

I'm extremely happy you're in support of unfication.

To begin with, the lead developers of Subway, Turbogears,
SQLObject/FormEncode, and Cherrypy [1] should get together for some
kind of chat or IRC session and hash out an agreement on principle
issues such as

- If there is a shared desire to work together towards one
megaframework
- Division of responsibilities
- Architectural issues (WSGI support, etc)
- User Marketing Strategy: How to attract further developers to the
cause.
- How to do it better than RoR
- Possible fundraising from python users
- etc...

[1] and perhaps some of the Templating module authors, but that may be
premature at this stage.

[Peter Hunt]

I actually think Ian Bicking should be in on this, too: we should get Paste on the bandwagon as well.

[Ian Bicking]

Howdy all...

Lethalman wrote:
> Only with these options:
> 1) Controllers as the subway way (not classes)

My impression is that there's not a huge commitment to the class
structure in TG, but the decorators are pretty essential. That doesn't
seem incompatible with Subway.

> 2) Cheetah and not kid

There's no way they'll switch to Kid. But configurable templates (or
just noticing .tmpl on a filename) is quite possible. I think with some
of these things the issue isn't technical, but documentation. They
(well, mostly Kevin) don't/doesn't want to document things in a
piecemeal fashion, or add complexity by presenting different options at
each turn.

> 3) Other subway features

Well sure, this is the thing you are offering in return for other
compromises ;) Kevin has added a bunch of developers fairly quickly, so
I don't think he's overly protective either.

Another option is for Subway's model to become another flavor instead of
a separate framework. If you use Cheetah, for instance, that might just
mean different scaffolding. Though, all considered, that's the only
really substantive difference I see. I think controller differences
should be resolveable. They aren't using schemabuilder in TG and some
other stuff, but even if that overlaps with other developments there I
see no reason why there wouldn't be room for both.

Anyway, if you guys want to move forward on this you should probably
move on this fast, since TurboGears is trying to quickly reach 1.0, and
the APIs are calcifying quickly as a result.

--
Ian Bicking | ia...@colorstudy.com | http://blog.ianbicking.org

[Mark Ramm]

> Only with these options:
> 1) Controllers as the subway way (not classes)
> 2) Cheetah and not kid
> 3) Other subway features
>
> Or even let the user choose what components to use. The web app should
> then support as many items as it can, providing an abstract layer for
> each of them. For example
> - FormEncode/Atocha
> - Cheetah/Kid
> - Class controllers/Filesystem controllers
> - and so on...

> Another thing... the tg administration interfaces (like catwalk and
> i18n) must be closed for now until products are in.

Wow, I think the TurboGears folks are interested in exploring the
possibility of a project merge, but this seems like quite a large list
of up-front non-negotiable items.

Before we get mired in the discussion of these points, perhaps we
ought to take a step back:

1) What can the TurboGears project gain from merging with subway?

2) What can the SubWay project gain from merging with TurboGears?

3) What can the python community gain from these two projects merging?

As a TurboGears and Python user, I feel like I am best equipped to
answer questions 2 and 3. But I think we need good answers to all
there of these questions if there is any chance to make this merger
fly.

I promise to write more on questions 2 and 3 this evening. But for
now, anybody have from this list have some good ideas for answering
question 1?

--Mark Ramm

[jorge....@gmail.com]

hi I come from TG, about your post could you elaborated a little more
on

Lethalman wrote:
> Only with these options:
> 1) Controllers as the subway way (not classes)
> 2) Cheetah and not kid

why if cheetah and I quote "Cheetah should make code reuse easy by
providing an object-oriented interface to templates that is accessible
from Python code or other Cheetah templates." you don't use classes for
the controller?

> 3) Other subway features
are you refering to http://www.gosubway.org/docs/helpers.shtml

> Or even let the user choose what components to use. The web app should
> then support as many items as it can, providing an abstract layer for
> each of them. For example
> - FormEncode/Atocha
> - Cheetah/Kid
> - Class controllers/Filesystem controllers
> - and so on...

That could be a solution but we need to think that will require a lot
since everything will have to be check a lot, and we will provide more
then one way to do the same thing, which is an overkill. On the other
hand one of the things about TG is aims to use the best for each part
of it.

> Another thing... the tg administration interfaces (like catwalk and
> i18n) must be closed for now until products are in.

you mean stop any changes on them?

[Lethalman]

Mark Ramm wrote:

1) Subway features which TurboGears has not
2) Popularity
3) All in one web frameworks

[Lethalman]

jorge....@gmail.com wrote:

>hi I come from TG, about your post could you elaborated a little more
>on
>
>Lethalman wrote:
>
>
>>Only with these options:
>>1) Controllers as the subway way (not classes)
>>2) Cheetah and not kid
>>
>>
>why if cheetah and I quote "Cheetah should make code reuse easy by
>providing an object-oriented interface to templates that is accessible
>from Python code or other Cheetah templates." you don't use classes for
>the controller?
>
>

Ok, no problems... sometimes classes are better. This is not the main
problem...

>>3) Other subway features
>>
>>
>are you refering to http://www.gosubway.org/docs/helpers.shtml
>
>

CherryFlow, form handling...

>>Another thing... the tg administration interfaces (like catwalk and
>>i18n) must be closed for now until products are in.
>>
>>
>
>you mean stop any changes on them?
>
>
>
>

I mean "do not make radical changes before products/plugins/extensions
are done", sorry i don't speak English well :)

[Mark Ramm]

> >1) What can the TurboGears project gain from merging with subway?

> >2) What can the SubWay project gain from merging with TurboGears?

> >3) What can the python community gain from these two projects merging?

> 1) Subway features which TurboGears has not

> 2) Popularity
> 3) All in one web frameworks

OK, 2 and 3 are very understandable to me. can you help me understand
1 better?

I'm sure Kevin is all for adding new features which Subway has and
TurboGears has not, but what are they?

My main concern is that if we accommodate to the "everything has to
work with cheetah and controllers can optionally not be classes" it
will hugely slow down TurboGears development, make testing very
difficult. This has to be weighed against what subway and the subway
developers can bring to the table.

I think the idea is great, but the devil is going to be in the details.

--Mark Ramm

[Lethalman]

Mark Ramm wrote:

>>>1) What can the TurboGears project gain from merging with subway?
>>>
>>>
>
>
>
>>>2) What can the SubWay project gain from merging with TurboGears?
>>>
>>>
>
>
>
>>>3) What can the python community gain from these two projects merging?
>>>
>>>
>
>
>
>>1) Subway features which TurboGears has not
>>2) Popularity
>>3) All in one web frameworks
>>
>>
>
>OK, 2 and 3 are very understandable to me. can you help me understand
>1 better?
>
>

2) Subway is more code-featured against TurboGears but marketing has
gone to TG
3) Create and collaborate to a unique framework so users don't get
painfully on choosing and increase development

>I'm sure Kevin is all for adding new features which Subway has and
>TurboGears has not, but what are they?
>
>
>

Form handling, cherryflow and other small things...

>My main concern is that if we accommodate to the "everything has to
>work with cheetah and controllers can optionally not be classes" it
>will hugely slow down TurboGears development, make testing very
>difficult. This has to be weighed against what subway and the subway
>developers can bring to the table.
>
>
>

Code is not a problem... much of the Subway code is made for non-class
controllers.

[aw]

I notice that this thread says that the marketing has gone to TG. I
only started using TG a few weeks ago. When I was looking for a Python
framework, it was mainly the difference in the 2 websites that sold me.

Subway's website is a lot of text. Few images much less screencasts.
Documentation, howto's, etc are harder to find. It may have more
features but I was not able to determine that at a glance.

TG has done a better job with documentation. It can be a lot better
but that is in process. I am really looking forward to the next few
devcasts because I really don't understand formencode.

[Lethalman]

aw wrote:

Marketing... manly how to attract people...

[Peter Hunt]

I don't have any non-negotiable items. I'm willing to talk it over.

TurboGears has a lot to gain from Subway. We do form handling in a pretty unique and convenient way, and we also have CherryFlow. Controllers are also automatically set up instead of manually added on the tree, and I think this is an important feature TG is lacking.

I think we should have an IRC meeting of everyone concerned.

Peter Hunt

[Lethalman]

On 12/20/05, Peter Hunt <floyd...@gmail.com> wrote:

>
> I think we should have an IRC meeting of everyone concerned.
>
> Peter Hunt
>

I do agree...