On Thu, Sep 2, 2010 at 3:05 PM, Hyrum K. Wright
<hyrum_wright_at_mail.utexas.edu> wrote:
>>> After our conversation on IRC, I did write a short test program to
>>> better investigate what the Java URI class accepted or balked at. I
>>> discovered (empirically, so definitely not completely comprehensive)
>>> that the URI class handles the various schemes we support just fine.
>>> The documentation also supports this: "a URI instance is little more
>>> than a structured string that supports the syntactic,
>>> scheme-independent operations of comparison, normalization,
>>> resolution, and relativization."
>>
>> What about performance implications? Depending how far you take this.
>> If I were retrieving log messages, with thousands of paths, I would
>> not want to introduce any extra clock cycles just so that SVN can
>> convert its string into some object it thinks I might want and so that
>> I can convert it back. Reading the JavaDoc for URI, it seems like it
>> must do some parsing of the string so I wonder how lightweight it is.
>
> If you are retrieving log messages with thousands of paths, the
> network latencies and other Subversion operations will vastly dominate
> transaction times. Whatever overhead you've got in doing whatever
> parsing the URI class does is minuscule in comparison. (Also, there
> isn't any URI-specific fields returned through log, so that example
> isn't particularly valid. Most of the places we exclusively provide
> URIs are not invoked inside loops.)
I would not be so sure. When you are dealing with a GUI, adding a
handful of milliseconds to something that is going to be done
thousands of times can add up to less responsiveness.
Also, I specifically acknowledged this API has not been changed. I am
asking you your intent. The API you changed so far is meaningless to
me, but I am assuming you have every intent of changing every API we
have as that has been the previous pattern and I am registering my
objections now before you invest the effort.
>>>> I think you should revert this.
>>>
>>> I understand your feelings. Subclipse is a very large consumer of the
>>> JavaHL API, and the bindings have largely evolved to meet the needs of
>>> this (very large) consumer. However, I'd like to hear what other
>>> opinions folks may have before I make any other changes (both
>>> reverting this change, as well as extending others in a similar vein).
>>
>> I do not agree with you there is any user value here. I am interested
>> to know the full scope you intend to take this. I think people are
>> just going to need to take the URL convert it to a String and then
>> maybe convert the String into what they wanted (though I suspect most
>> will want String).
>>
>> I do not see why we would return URI if we do not accept URI into the API.
>
> We return *much* more information that we accept into the API.
Of course. But very few of these items you refer to are ever fed back
into the API. Again, I ask the intent of how far you plan to go with
this? Why would you change one API if you do not plan changing all of
them? If all the API's return URI's then soon you will want to change
the input as was discussed yesterday. Or at a minimum it is going to
bother you that we return URI but ask for String.
> I'm not opposed to making similar
> changes to the input APIs (such as with the upgrade API). As an API
> consumer, I'd much rather find out about a type-based error at
> compile-time than run-time, especially when my language of choice
> provides that capability.
I understand and on a micro level this makes sense. When we took this
approach in Subclipse it certainly looked like an improvement on the
API to use classes like File and URL in place of String. When you
look at one single Interface like ISVNClient that already has a ton of
methods, and then you start taking methods like copy and adding a
variant for every combination of File and URL it can accept it gets
ugly quick. Factor in future releases where we rev the API and it
gets uglier. In my usage of the API I also get little benefit as I
tend to have to convert what I am working with to a File or URL before
calling the API so it would be easier if it had just been String.
> Again, in an effort to understand the other implications of these
> types of changes, I'm interested to hear what thoughts others have on
> this subject.
Same here. I'll just repeat that I do not think it is going to help
someone using our API to know they are going to receive URI in place
of String.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Received on 2010-09-02 21:18:21 CEST