On Wed, Feb 4, 2009 at 3:13 PM, Hyrum K. Wright
<hyrum_wright_at_mail.utexas.edu> wrote:
> Mark Phippard wrote:
>>> As Hyrum pointed out, there are several bindings in existence
>>> that are being maintained out-of-tree already.
>>> So this is a solved problem!
>>
>> Sorry, but bullshit. Just because people like Bert have put in effort
>> to create bindings does not mean the problem is solved. Someone would
>> have to recreate all this work for each of the bindings as they
>> spinoff in their own projects. The stuff Bert did for SharpSVN is not
>> going to help JavaHL etc. I am not saying the problem is in using our
>> libraries from bindings, but creating and maintaining a working
>> development environment.
>>
>> BTW, I bet that Bert has no desire to move SharpSVN into our project.
>> He probably likes that he can add features and release on his own
>> timeline. If I were building Java bindings today, I'd feel the same.
>> But the bindings have been in the project from the beginning and now
>> there are tools like Subclipse that exist and depend on them being
>> consistently delivered along with the core libraries.
>
> But the bindings are rarely delivered to the end user along with the core
> libraries. Most *nix distributions put the bindings into separate packages
> to reduce footprint and dependencies. We even distribute such packages for
> windows on s.t.o. I posit that the same experience which exists today could
> be had even if the bindings are in a different package.
I agree that is a possibility. But it is also possible that with
these bindings spun off as separate projects the distros decide to
drop them just as we did. It is also possible that the bindings will
not be available until weeks/months after a release and not make it
into a distro. It is also possible that the bindings will wither and
die because no one wants to maintain them on a daily basis and then we
ship a release the delta is too daunting to bring them up to date.
It is also possible the bindings would flourish as separate projects
which allowed them to be enhanced on their own schedule and attract
more maintainers than they have today.
Anything is possible.
>>>> There is a lot of stuff out there that is built up around these
>>>> various bindings and this sort of change could wind up creating chaos.
>>>
>>> If that was so, then anyone maintaining any kind of code against our
>>> APIs outside of our tree would wind up in chaos as well.
>>>
>>> I think the API stability we provide is all that's necessary to
>>> successfully maintain the bindings. I'm not a bindings developer,
>>> so I cannot speak from my own experience. But it looks like there
>>> are enough examples out there that justify this point of view.
>>
>> Again, you misinterpret. Our API is fine and if I were building a new
>> binding today I'd agree. I am saying there is an ecosystem out there
>> of tools that use our API via the bindings. To suddenly make those
>> separate could suddenly create chaos for the tools that expected them
>> to be available.
>
> I still wonder about this. Again, most people install the bindings via
> their operating system package manager. Heck, if the bindings were
> distributed separately, it might make it *easier* for tools to use them,
> since the bindings have a much smaller footprint and could feasibly be
> shipped with the tool itself.
When JavaHL was immature, I used to long for them to be maintained
separately. So when a SVN feature was not exposed, I could add it to
JavaHL and start using it. Over time, I came to realize that would
not work though.
1) As a consumer of JavaHL, I need a way for my users to get the
library. So I cannot just update it with new features and get that in
their hands. I need to wait for it to flow through the distros.
Let's face it, that is not going to happen quickly.
2) As a maintainer of a fairly complex SVN client, even though the SVN
API is stable and all, I cannot realistically make a client that can
work with any version of the API available. Too much of the UI and
behavior I expose is dependent on my knowledge of how the API behaves.
Could I conceivably condition all my behavior and UI based on the
version I find at runtime? Maybe, but I sure as heck do not want to.
This is not an issue for TortoiseSVN and AnkhSVN because they can
control the libraries the user is using. For Subclipse, partly
because we are cross-platform, we depend on the libraries they have
installed. Anyway, my point here is that I quickly realized that
programming to the "stability" of SVN's release cycle makes my app
better and easier to maintain. If I had to code to a JavaHL that was
maintained on its own schedule, I just could not do it.
>>>> Also, as you touched on, while the bindings can be a PITA it is also
>>>> hard to know how many release problems they have prevented by the
>>>> things they uncovered. Things are a little better now because of the
>>>> buildbot you added. Perhaps this can ultimately help this get better
>>>> by spotting failures sooner.
>>>
>>> That is the only point that concerns me, too. However, nothing stops
>>> anyone from running any kinds of tests involving bindings against
>>> our trunk on a regular basis. It's just that it's already set up
>>> in an in-tree fashion right now. But there is no technical reason
>>> why this advantage the bindings offer would have to go away if
>>> they were being maintained out-of-tree.
>>
>> I think it comes down to timing. If I were maintaining a binding,
>> odds are I would not be updating it with our trunk on a daily basis.
>> At best, when we got to a RC phase I'd look into updating them and
>> only then might I find the problems and be able to report them. We
>> saw some of this with 1.5 where the problems with the API found
>> downstream did not show up into right before the final release. The
>> bindings MAYBE allow us to catch some of these problems sooner.
>
> Only if they are being maintained. If they aren't being maintained, they
> cause more problems due to bit rot than they are worth. And with all due
> respect to Kou and Joe, we've seen this problem with the swig-ruby bindings
> time and again. (I suspect the other bindings would exhibit the same
> problems, were it not for their lack of comprehensive test suites.)
With the same respect to Kou and Joe, and also with some ignorance on
the "details", a problem I see with the Ruby bindings is that one the
one hand, they have a comprehensive test suite, on the other they have
a test suite that is more brittle than the bindings themselves. For
example, they seem to have a test that calls just about every API.
When a new parameter is added to one of our API's the bindings
themselves get updated automatically, but someone has to go into the
Ruby test itself and account for this. This is only a problem during
a release cycle when a new API is evolving, but it seemed to be the
common problem during the 1.5 end-game. I do not have any answers to
this, just that the tests for the Ruby bindings seem to often be the
problem, not the bindings themselves.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1103888
Received on 2009-02-04 21:30:21 CET