> On Aug. 16, 2014, 7:46 p.m., Denis Steckelmacher wrote: > > Great work! I've tested this patch in this configuration and it works: no > > PySVN, SVN installed, Python 2. I have one question, though: why do you try > > to get the temporary path for the cached file using three different > > OS-dependent methods while you have an OS-independent fallback? Why not > > directly use tempfile.gettempdir? > > Alex Merry wrote: > I wanted to avoid using a temporary directory, as this is really a > caching thing (temporary directories are generally intended for things that > won't last longer than a single execution of the program). > > Admittedly, it's debatable in this case, since we're not maintaining it > for more than an hour (although it's still useful to keep around for longer > in case you lose the internet connection). > > Denis Steckelmacher wrote: > Yes, I understand, but as you point out, 1 hour is a very short delay and > I don't think that anybody has its /tmp directory automatically cleaned after > one hour. If I remember well, /tmp is generally not cleaned before a computer > reboot (it is either stored in RAM, or a shutdown script removes everything > in it). > > On the other hand, api.kde.org is generated only once a day, and most > maintainers are "stable" and will not change name/email every hour. So, I see > two solutions: > > * Keep the one hour delay but put everything in /tmp > * Keep your cache paths but change the delay so that one day (or two) are > allowed to pass before the file is re-downloaded. > > It is also possible to use /tmp and a big delay, which is the simplest > solution, but then some people will download the file a bit more often than > expected because they have rebooted their computer. But in a world where > people don't reboot their computer but put it to sleep, I don't think that > this is really a problem.
I would consider leaving stuff around in /tmp after exiting somewhat antisocial behaviour on the part of an application. I think you have a point about not needing to update every hour, though. I'll boost that to a little under a day (so that api.kde.org always gets a fresh copy, but developers only update once a day). - Alex ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119805/#review64653 ----------------------------------------------------------- On Aug. 16, 2014, 3:29 p.m., Alex Merry wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/119805/ > ----------------------------------------------------------- > > (Updated Aug. 16, 2014, 3:29 p.m.) > > > Review request for KDE Frameworks, Denis Steckelmacher and Aurélien Gâteau. > > > Repository: kapidox > > > Description > ------- > > WebSVN is not set up to deal with a large number of hits - it is > intended for casual browsing. "svn export" is much more efficient, and > the anonsvn servers are meant to take this load. > > Given that we would like developers to be generating documentation to > check their doxygen markup, we should use a method that scales. > > This uses "svn export" (either through libsvn python bindings or the > command-line utility) if it can. It also caches the result for an hour > (since the accounts file is only updated server-side once an hour > anyway). > > > Diffs > ----- > > src/kapidox/generator.py ba4fad92d4b027d791107c58b15b26187d6f3087 > > Diff: https://git.reviewboard.kde.org/r/119805/diff/ > > > Testing > ------- > > Extracted download_kde_identities() function (and its dependent functions) to > another script, and tested with python2 (with libsvn bindings), python3 > (without) and python3 (with the svn command line altered so that it would > fall back to websvn) - both with and without a cache file/cache directory > present. > > Also ran kgenframeworksapidox (python2), and checked that David Faure was > correctly listed as the maintainer of KArchive, with an email address. > > > Thanks, > > Alex Merry > >
_______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
