On 14.04.2011 21:03, Daniel Shahaf wrote: > On Thu, 14 Apr 2011 14:43 -0400, "C. Michael Pilato" <cmpil...@collab.net> > wrote: >> On 04/13/2011 06:52 PM, Stefan Fuhrmann wrote: >>> The code in question has evolved over many months so it is >>> very possible that the name of svn_fs_get_cache_config() >>> and friends is no longer appropriate. The same goes for the >>> place that this has been implemented. >>> >>> From a design perspective, I think it is perfectly to o.k. to >>> expose resource limits on the server UI level. The fact that FSFS >>> is currently the only part of the server that uses these settings >>> does not change, IMO, the fact that they are part of the UI. >> I don't have an opinion about exposing resource limits via the server >> UI. I do have a strong opinion about the code honoring the flow of the >> layered library design we have. If you want to tweak server settings >> from client code, you need to do so via the RA vtable(), implementing >> the logic to do so (or to expressed *not* do so) in every RA provider. >> >> On 04/13/2011 06:52 PM, Stefan Fuhrmann wrote: >>> Maybe we should simply move the function in question to libsvn_subr >>> and rename them properly. >> On 04/13/2011 11:12 PM, Daniel Shahaf wrote: >>> I assumed the resolution would be to move that function to libsvn_fs, not >>> to libsvn_subr... >> I'm honestly not quite sure exactly where the right place is. I don't >> really see what moving it to libsvn_fs does for us -- IMO, it's still >> wrong for svn_ra_initialize() call into that. (libsvn_ra should only >> call into libsvn_subr, libsvn_delta, and its own RA provider vtable.) > Would svn_cmdline_init() be a better place to call the init > function from?
Clearly not, since that function is a startup helper for command-line programs, not for libraries. -- Brane
