On Tue, Dec 19, 2000 at 12:50:29PM -0600, Karl Fogel wrote:
> Greg Stein <gstein@lyra.org> writes:
> > I'm finding it rather annoying that svn_wc_prop_get() takes an svn_string_t.
> > I've got a couple fixed names for properties and need to keep constructing
> > an svn_string_t to deal with the props.
> >
> > Should I:
> >
> > 1) create a second interface that takes a "const char *"
> > or
> > 2) change the prototype for svn_wc_prop_get/set ?
>
> Hmmm.
>
> I'm sorry to do this to you, but could you create a second interface?
Sure, but per another email, I don't think the svn_wc_prop_get/set
interfaces work in concept. So this question is effectively moot until we
have a proper resolution on fetching this information.
> Binary properties (both name and value) are permissible, so we need to
> use svn_string_t. I confess that having a binary *name* is unlikely,
> and probably suffers from the same XML attribute problem in our DTD
> that filenames suffer from. But adding to the problem won't help
> us. :-)
Urg. -1 on binary property names. As I've said before, property names should
be URIs. If we don't require URIs, then property names (between two
different tools) could conflict. And binary names certainly can't be mapped
into a URI :-)
[ there is also my desire to map our property names directly into DAV
property names (unless somebody can explain why we shouldn't). and DAV
prop names are URIs. ]
Can somebody give a rational reason for not using URIs for prop names? Other
than "that would be neat and the most flexible solution." Any requirements?
Use cases that need a binary property name?
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Received on Sat Oct 21 14:36:17 2006