(Take 4. First 3 attempts didn't show up. Sorry if this is a duplicate.)
I brought up this idea a while back, and one person seemed to think it
was a good idea, but I wanted to solicit others' ideas before adding
this as an official task in the issue tracker.
It looks like there are attempts in different binding layers to define
an OO interface on top of the subversion API.
o First, there was svn_cpp, part of RapidSVN
o Next was the OO Python bindings, based on svn_cpp
o Today a discussion was started about OO Perl bindings.
o When I brought up COM, someone suggested basing the
hierarchy on svn_cpp
My question is this: Is it within the scope of the subversion product
itself to define what an class hierarchy should look like for an OO
binding? I'm not suggesting that it's the responsibility of the
Subversion project to actually *implement* any of those wrappers, or
necessarily *include* them in an official distribution (though that
would be nice). I just believe that for consistency's sake, there ought
to be a single, official class hierarchy and API definition for any OO
bindings that come down the pike. The subversion team would be
responsible for defining and documenting the classes and their
hierarchy/properties/methods, but not necessarily for implementing them
in any particular language.
What's the collective opinion? Should we add a TASK issue (Post-1.0,
probably) to define an official OO API structure?
S_E_D
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Dec 18 17:20:08 2003