[Dev] Re: refcounted

[Katie Capps Parlante]

Heikki,

I think most of us agree with you, and setting ourselves up to be able 
to switch to java (or any other language) on a dime is a non-goal. The 
various discussions we've had about how we'd make the repository 
accessible in another language have convinced most of us that this is 
possible at a later date, with some work, and that is good enough for now.

As for the pinning api, I think we need to respect the various +1 votes 
that pinning is not a keeper. Over the long term, maintaining the code 
in two ways is likely to make the repository more fragile. That said, 
Andi is owner of this code, and its up to him to decide when he's 
comfortable removing it, or whether he needs to make another argument to 
convince people the pinning code is needed.

In the short term, I don't think its a good use of cycles at this stage 
to keep arguing about the default value, which is a superficial symptom 
of the real issue. We're perfectly capable of making the unit tests work 
either way, and we should go just do that. We've come to an agreement to 
try and make non-pinning work, lets focus on that right now.

Cheers,
Katie

Heikki Toivonen wrote:

> Andi Vajda wrote:
> 
>> I'm just using the Java argument as a way to not paint ourselves into 
>> a python-only corner too much. It's important to keep nimbleness at 
>> hand, it always comes in handy when you least expect it.
> 
> 
> This talk about trying to maintain the possibility of easily switching 
> languages seems folly to me. I would have thought the language argument 
> was settled a long time ago. If we still are not sure, I'd call this a 
> major problem. Also, there is a cost associated in trying to make it 
> easy to switch languages.
> 
> Mozilla did not seriously consider changing the main programming 
> language since 1998 (although more and more code was written in 
> JavaScript instead of C++ and C - but then performance work reversed 
> some of those decisions). Likewise, Mozilla never tried to make it easy 
> to switch to another language (although limiting C++ features to a 
> subset that worked with most compilers may have achieved some of that). 
> Yet it took at least four years (or six if you think Firefox 1.0 will 
> mark Mozilla's success) before there was a great product that could 
> stand up to its competitors.
> 
> Some reasons why it took so long for Mozilla included overly ambitious 
> modular architecture and Mozilla platform work. The modular architecture 
> is still being scaled down, and the platform - while powerful - lacks 
> tools to really make it easy to use. (Netscape saw back in 2000 that the 
> work needed to be shifted towards producing a browser if we wanted to 
> get something usable as a browser out.)
> 
> In Chandler we are also building a platform. We are also trying to make 
> it easily extensible. Those are costing us. I am not saying we should 
> not be doing those, but we must balance those with the needs of shipping 
> a product. I fear that adding even more ambitious goals to the mix will 
> push a usable product so far into the future that we don't even see it.
> 
> 
> ------------------------------------------------------------------------
> 
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> 
> Open Source Applications Foundation "Dev" mailing list
> http://lists.osafoundation.org/mailman/listinfo/dev