| bf8de10e1e04cd6019ba4e23ebebcc1eaee5d4ba 96195 |
|
25-Jul-2002 |
gstein |
In some application environments, the mod_dav hook structures are
allocated dynamically. The structures need a context pointer to
represent that dynamic "object", so a pointer was added to the end of
each of the more important structures.
While providers don't need to add this field to their structures (it
will default to NULL), I went ahead and added it to mod_dav_fs for
clarity.
No MMN bump is required because Apache does not use/examine the
fields (only the provider will set and use them). |
| 10d15a1817ddd19094a70ed0f7e4efc6a56f449f 91065 |
|
18-Sep-2001 |
gstein |
Revamp the API that mod_dav uses to talk to back end deadprop (propdb)
providers. The old API was really based on how the FS stored properties, but
sucked for other types of providers (SQL databases, Subversion, etc). This
new code is overall much cleaner as it moves from a DBM style API to one
tuned for actual mod_dav operation; it also more flexible/clearer for future
improvements (e.g. dropping props directly to the wire rather than buffering
in memory).
This new API allows the provider to better define namespace handling during
the output of the values, how values are serialized and stored, the mapping
between elements' namespaces and the internalized namespace storage, a
clearer mechanism for naming properties (dav_prop_name), and an explicit
rollback mechanism to deal with PROPPATCH atomicity.
Updated the FS provider (fs/dbm.c) to the new API, mostly by moving code
from main/props.c. Of course, with the new semantics, some big changes in
the namespace mapping were made. |
| 7a4999217dfa98039f66724f390511e3a4e4ae8c 91064 |
|
18-Sep-2001 |
gstein |
Now that we have apr_datum_t, convert some uses of dav_datum over to
apr_datum_t (the two are equivalent).
Expose some of the DAVFS' internal DBM cover functions and have the locking
code use them directly, rather than thru the vtable. That vtable will be
changing shortly, so this shift is needed. |