[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

API issues we might want to solve for 1.0

From: Greg Hudson <ghudson_at_MIT.EDU>
Date: 2003-12-12 17:02:08 CET

As it's much easier to make API changes before 1.0 than after, here
are a list of issues we might want to solve soon. The first three
seem important; the rest are just unfortunate foibles (except for #6,
but that would require a serious push to fix). Many of these have
received attention in the past, but time marched on without anyone
fixing them.

  #1: We define symbols in the APR namespace:
        In svn_sorts.h: apr_hash_sorted_keys
        In svn_types.h: APR_ARRAY_IDX
  IMPACT OF PROBLEM: We're not very sociable, and might conflict with
      a future version of APR which includes these symbols.
  DIFFICULTY OF FIX: Depends on how we fix them.

  #2: The svn_client interface accepts a pointer to a context
      structure which is allocated by the caller and filled in by the
  IMPACT OF PROBLEM: We have no way of extending this structure with
      new fields. We should provide a function to create and
      initialize a context structure and mandate that the caller use

  #3: Recursion is specified as a boolean in svn_ra operations, but
      we have vague plans to support either tri-state (0/1/infinity)
      recursion or arbitrary recursion depth.
  IMPACT OF PROBLEM: Supporting enhanced recursion will require a
      difficult API change.
  DIFFICULTY OF FIX: Medium; we need to agree on a new API, and then
      all ra layers need a trivial change across half a dozen

  #4: Even though we introduced "" as a no-op path element years ago,
      svn_wc_get_actual_target() returns NULL in *target if anchor is
      the actual target, and various APIs support NULL path elements
      for compatibility with that.
  IMPACT OF PROBLEM: API is somewhat inconsistent and confusing.
      Fixing after 1.0 is unlikely to ever be worth the effort.
  DIFFICULTY OF FIX: Medium, and with some change of destabilization.
      (I had a go at this in issue #999.)

  #5: svn_ra_init_ra_libs and friends use a void * baton instead of an
      opaque type.
  IMPACT OF PROBLEM: The interface is needlessly non-type-safe.

  #6: We still use getdate.y, which implements a bizarre and arbitrary
      set of date formats. (Did you know that "3" is a date?)
  IMPACT OF PROBLEM: We'll be stuck with getdate.y forever.
  DIFFICULTY OF FIX: Major. And we already have people (including
      developers) relying on getdate's foibles. Bleah.

  #7: Overly defensive programming in:
      The path_uri functions actually document that they will pass
      through NULL, even though there is no use case which makes that
      especially convenient. svn_cstring_split_append accepts a NULL
      input even though it is not documented that it does so.
  IMPACT OF PROBLEM: Minor; we will be trapped into providing
      interface guarantees for these functions which we don't provide
      most places.

  #8: log_message_receiver_t accepts a hash of changed paths instead
      of an array. This appears to be for the convenience of existing
  IMPACT OF PROBLEM: Minor; changed_paths is not a pointer to const
      since you can't iterate over a const hash table.

  #9: log_message_receiver_t and commit_callback_t pass dates as const
      char * instead of apr_time_t, as a nod to the fact that dates
      are stored as text properties on revisions.
  IMPACT OF PROBLEM: API is not as clean as it could be; users of
      those types must perform extra input validation because of the
      possibility of malformed date strings.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Dec 12 17:06:02 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.