> An API as simple as the command-line client would be as limited as the
> command-line client: no error-handling beyond success or failure except
> by recognizing error strings (brittle); no complicated information in or
> out, such as the information required for a log message, without parsing
> strings (complicated and brittle); no fine control over what to do with
> informational output.
- didn't know that the command line client is limited...
- 'standard' ways of handling complicated information is to use 'standard'
i.e. base types like arrays of strings, ...
> Really, all you could make with an API like that is a command-line
> client, which we have, or a GUI which feels like a thin layer on top of
> a command-line client, which we don't want. For a good GUI you want
> something more structured.
agreed. But only if you want a GUI only for Subversion. Addins for IDE's
and Editors sometimes simply can't be more structured.
> The baton is a piece of data passed to the notify function. (Other APIs
> sometimes call that "userdata".) If we take out the baton, there is no
> way to get information to the notify function except through global
> variables. Global variables work fine for simple applications, but
> don't scale to the complicated ones.
ok, but then why not give a description of what the baton is about in
the description of the function? Especially if you use apr batons - its
very time consuming to look through all the header to find the declarations
of the batons and even more to find out what they are for.
>
> > - handle the apr_pool_t *pool internally
>
> This might be a good idea for libsvn_client, since the interface is very
> granular. Unfortunately, if you get an error back, the memory for that
> error comes from a pool, and we can't really "handle" that internally.
hmmm - the command line client does that.
if not: if you can't handle that internally, how can it be handled by a
client?
>
> > - instead of the auth_baton use 'username' and 'password' - thats more
> > understandable
>
> But there are more ways to authenticate than by username and password.
then simply provide other functions (that's called overloading) with those
other
authentication parameters.
>
> > - avoid structs for the api, use the data of the struct directly
>
> Glancing over svn_client, it looks we have a good reason to use
> structures in each of the places we do so. (Although I am concerned
> about the auth baton; that structure will almost certainly need to grow,
> which could affect our ABI.)
but there are programming languages which don't support structures directly.
And for those it's easier to cast 'basic' types to the required ones than
structures.
> > - if you use structs for the api, declare them inside the same header as
the
> > functions.
>
> Not really practical. And in general, if you don't understand what a
> type is, your first questions should not be "what fields does it have?"
> but "what is it for" and "how do I make and manipulate it?" Those we
> can answer without a declaration in the same header file.
that's only true if you write a GUI in C or C++. For other languages you
need to know what fields it has, what types the fields are. And if you have
structures inside structures inside structures... you spend a lot of time
doing that.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Aug 25 21:25:47 2002