http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]&by=thread&from=683184
Martin, Peter and I discussed how the structure of the history folder should look like. Currently there will be one folder for each versioned resource directly under /history. However, this leads to performance problems as described in
http://thread.gmane.org/gmane.comp.jakarta.slide.user/2366
Martin has a patch that does what it is suggested in the above message and the below text contains a possible path to go for 2.1
Looking for comments and opinions.
Oliver
Martin Holz wrote:
Oliver Zeigermann <[EMAIL PROTECTED]> writes:
[EMAIL PROTECTED] wrote:
-----Original Message----- From: Oliver Zeigermann [mailto:[EMAIL PROTECTED] Sent: Monday, March 29, 2004 17:20 To: Slide Developers Mailing List Subject: Re: How about RC1?
OK, I see now and am convinced. The patch proposed by Martin to use /history/1/2/h3 instead of /history/123 is nice to reduce the number of resources in a folder anyway, right?
Yes, it is. I haven't seen the patch in detail. I think we have to be careful with parts of the code, where an URI is analyzed to determine whether it belongs to a history or a version. Probably, currently ${historypath}/xxx would be taken for a history URI, ${historypath}/xxx/yyy would taken for a version URI, and ${historypath}/xxx/yyy/zzz would be rejected as invalid.
In Martins patch /history, /history/1, /history/1/2, etc. are history URIs and /history/h1, /history/1/h1, /history/1/2/h1 are version URIs I guess. I understand your reservation, but on the other hand Martins solution takes of the performance problem.
What should we do?
Maybe, an init-parameter "generateBalancedHistoryURIs" (or the like) in web.xml to be able to switch-off or customize the new behaviour would be nice? Comments?
This sounds like a good idea. Martin, do you agree?
I did changes to two files: URIHandler and DeltaVConstants.
In DeltaVConstants only the I_INITIAL_HISTORY_NAME changed to 10.
However some of the constants in DeltaVConstants should be private to URIHandler anyway.
So URIHandler could be pluggable if HistoryPathHandler would not inherit from URIHandler. Also my patch does handle only versions, not workspaces, which
will probably have the same problem. So I would suggest to refactor the
WebDAV library so that the UriHandler is pluggable. But that should be left to slide 2.1. Does the testsuite cover DeltaV? This would be really usefull for refactoring.
Martin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
