On Thu, Sep 2, 2010 at 1:42 PM, Mark Phippard <markphip_at_gmail.com> wrote:
> On Thu, Sep 2, 2010 at 2:33 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 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. When
returning information, we also *know* what type of information we
have, rather than having go guess based upon the open-ended input
APIs. In cases where we *know* that we accept exclusively working
copy paths or repository URIs, 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.
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.
-Hyrum
Received on 2010-09-02 21:06:52 CEST