On Apr 12, 2007, at 19:01, David James wrote:
> On 4/12/07, Sage La Torra <sagelt@gmail.com> wrote:
>> On 4/12/07, Barry Scott <barry@barrys-emacs.org> wrote:
>> >
>> > David,
>> >
>> > Where will the design of the high level API be discussed?
>> >
>> > From your examples I already have feedback and questions.
>> > I don't want to wade in with lots of comments until you are
>> > up and running.
>> >
>>
>> Well, I just got the official acceptance for my Google Summer of Code
>> project to work with David on the bindings, so I'll be trying to step
>> up and take a greater role. As for being 'up and running,' that
>> should
>> be soon, I'll be sure to let the mailing list know.
>
> Congratulations Sage! It'll be great to have your help.
>
> Barry, I'm hoping to look at pysvn's interface and see what lessons we
> can learn from your design. I just took a very quick look and noticed
> that pysvn does not yet support multiple RA operations in a single
> transaction, so perhaps we can work together on defining an interface
> for this. You can read more details about my design at
> http://svn.haxx.se/dev/archive-2007-04/0425.shtml
O.k. this is your goals and an outline of the main class behavior.
Is it your intention to ignore the svn client API and build on RA
and WC?
In apps I do most operations to the WC which needs to be solved
and if by passing the svn client API means operations like getting
all the props for the files can work a acceptable performance for GUI
apps (the svn client API is very slow for this).
It is useful for users to be able to leverage there knowledge of the
SVN command line to write tools in python. Exposing the svn client
API pysvn affectively does this.
> Barry, please feel free to send any design feedback you have to the
> dev@ list. (If you feel up to it, you can even send design suggestions
> or proposals. Any help is welcome!). Just add Sage and me to the CC
> list and we'll get back to you.
>
Please see words and not abbreviations in symbols. Use delete not rm
use copy not cp. use transaction not txn, etc.
The svn client API has a bad habit of asserting if user input is
invalid. pysvn
protects the python user from problem. Any high level API svn most
not allow
the python process to be aborted by an assert just because a string
does not
have the right syntax.
What is the design for authentication? Passing username and password
to function calls is very limiting given svn's authentication call
back system.
pysvn allows the defaults for username and password to be set on the
Client()
object and that covers a large number of use cases for users.
By setting the Client().callback_get_login allows an app to react to
the svn call back
and pop up dialogs or whatever. The same goes for providing the log
message,
its done via call_get_log_message.
What is the plan for the API as svn adds features with regards to
backwards
compatibility? You will see in the pysvn implementation that I can
often support
multiple version of svn's API by adding additional keyword parameters
to an existing
function like ls(), but an a certain point svn API will change to far
and I'll add a new
function, which happened to support list().
You might like to try writing the outline of the reference
documentation and see if the
design is explainable.
Barry
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Apr 15 19:57:22 2007