scott.haug@gmail.com wrote on 08/31/2006 05:54:00 PM:
> I understand the difference, and what javasvn provides. I'm not
suggesting
> (anymore!) you write your own version. I guess I'm asking if the
> JhlClientAdapter works with the javasvn implementation of the javahl
APIs,
> or does it only support the native implementation? If JhlClientAdapter
works
> with javasvn as the SVNClient implementation, why have an explicit
> JavaSvnClientAdapter?
No, it doesn't. Which is not to say that it would have been impossible to
have made one that could do both. If you compare the two classes, the
differences are fairly obvious. The point of creating the Abstract class
was to keep the common parts in one place. That is what makes sense to
me.
> Maybe I'm missing something in the svnclientadapter API, then. As I
> understand it, there's a JavaSvnClientAdapter, a JhlClientAdapter, and a
> separate factory for each. The adapters both extend the same base class,
but
> one is not a subclass of the other. So, clearly, there is some
distinction
> in the functionality they provide, even though the vast bulk of their
> implementation is provided by the AbstractJhlClientAdapter base class.
My
> question, then, is would it make sense to have a single factory that
could
> detect whether javasvn or the native impl is in use, and return the
> appropriate adapter? Is this functionality already in place somewhere
and
> I'm missing it, or is there a reason I'm not understanding for
explicitly
> enabling these two clients separately?
I fail to see the benefit of that approach. How could explicitly pick the
implementation you wanted if they were both available? The current
approach seems like the proper OO-way to do this. As an example,
Subclipse operates under the assumption that all of the adapters might be
available and you can pick the one you want. If you have chosen a
default, we try to load it and have some fallback options if it fails. But
if it doesn't fail, startup is faster since only one adapter is
initialized. If you do not have a default chosen we try to load JavaHL,
if it is not available we try to load JavaSVN etc..
In our Eclipse proposal, we have changed this to be done with Eclipse
extension points. So the extension point will tell us which adapters are
available.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subclipse.tigris.org
For additional commands, e-mail: dev-help@subclipse.tigris.org
Received on Fri Sep 1 01:35:48 2006