[Twisted-web] Re: [Nevow-commits] r3904 - server-side (fragment) nesting, and convenience descriptor generator

[Andrea Arcangeli]

On Thu, Jan 12, 2006 at 04:48:21PM +0100, Valentino Volonghi wrote:
> Where something is located doesn't matter that much. It's still code that has

Where something is located doesn't matter, but having to checkout 10
different things when a single checkout command would make it the same
way, seems quite unnecessary to me.

If we were talking about huge repositories, then saving network
bandwidth and disk space could make sense, but for small things that
totally depends on nevow, the annoyance is more than the benefit. 

> I wouldn't walk this path at all. We are providing backwards compatibility for
> nevow versions that are long gone and we will provide it even when moving to
> web2. But notice that nevow is quite a bit different than python in many ways.

Yes, and I can report that I had zero breakages in my code so far. But
moving away from formless isn't going to be trivial and infact I'm
deferring it as long as I can, because I don't want to risk forms to
suddently change API after I ported to it. The later I move into forms,
the less risk of wasting time ;)

> But still even bigger projects break backwards compatibility (Zope, Python
> itself, Cherrypy between version 2 and 2.1, Ruby on Rails itself) when needed.

Even the kernel does.

But here I'm seeing quite a few projects being advertized and after one
year going in "obsolete" mode and being replaced right away with
something else written from scratch. Atop is one example. It's not all
necessairly bad, but especially after seeing atop, I wouldn't even dream
to touch axiom for example. I've to thank you a lot for suggesting me to
use postgresql as backend, that was a good and correct choice for my web
apps.

> To be honest I don't care that much. I do as much as I can to help people and
> to develop Nevow with the time I have available. If people is so stupid to
> leave a project because it is evolving to help developing with it then fine, I
> don't care at all.

I was especially talking about breaking stuff without a good reason for
it.

I trust you for the direction of the project, my message is more a
"think twice before breaking stuff", than "never break anything". I
perfectly know sometime something has to be broken sometime.

But I wanted to make my point that porting from formless isn't trivial
and that obsoleting formless may hurt some users currently depending on
it.

> As I said we will have backwards compatibility code. Worrying about something
> that is not even started seems a bit out of place. I have applications that
> run on Nevow too and I won't be happy to fix them all indeed.

I'm not worried, I'm sending my opinion before it starts exactly to
perhaps influence future decision.

I wouldn't like a project that never evolves because it's forced to
remain backwards compatible, but at the same time when major apis are
obsoleted and replaced right away, something smells like not enough
attention is being paid.

One perfect example of this, is how can I be getting a formless
deprecation warnings if formless is obsolete? Who had this idea of
changing formless with yet another API? formless currently asks me to
add some bind method and to stop using the interfaces. So now we've
_two_ formless APIs, and both of them going obsolete soon. I'm certainly
not porting my code to the new-formless-already-obsolete API when I know
I will have to switch to forms in a year or so. And furthermore I'm not
even switching to forms until I'm forced to, to reduce the probability
of forms breakages.

So I think I'm right asking to be more careful, because this new
bind method formless API is the proof some effort is being wasted.