Re: svn commit: r992041 - in /subversion/trunk/subversion/bindings/javahl: native/CreateJ.cpp src/org/apache/subversion/javahl/CommitItem.java src/org/tigris/subversion/javahl/CommitItem.java tests/org/apache/subversion/javahl/SVNTests.java

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.

>> 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.

-- 
Thanks
Mark Phippard
http://markphip.blogspot.com/