|
From: Sander V. <San...@Su...> - 2002-10-02 12:52:55
|
On Wed, 2 Oct 2002, Malcolm Tredinnick wrote: > Hi Benjamin, > > (1) We use mkstemp to generate a unique filename each time (and include > our own implementation for use on systems that don't have mkstemp). > > Advantages: > - Avoids the recent security problem (which is fixed in > CVS, btw). > - Gets around the "maximum of five files" problem. > > Disadvantages: > - There is going to be a metric truckload of files with > stupid names floating around in some subdirectory of > the tmp directory after a while. In reality, these are > never going to be cleaned up except by something like > tmpwatch (which is not frequent enough on, say, Linux > systems). > I think we should just declear cleaning these up the responsibility of whatever app uses scrollkeeper 8-) > (2) The scrollkeeper-get-cl binary dumps the result to stdout, rather > than saving to a file. > > Advantages: > - Never have to worry about stray files lying around. > - Makes scrollkeeper easily multiuser without having to > sweat on a lot of the locking issues all the time. > > Disadvantages: > - Breaks backwards compatibility. All applications > currently using scrollkeeper via scrolkeeper-get-cl > and friends. > > Although option (2) seems clearly preferable to me, the backwards > compatibility issues means it is probably an 0.5 feature. This means we > may have to go with the "dozens of stupid temporary" files in the > 0.3/0.4 timeframe unless somebody can come up with a better idea. > this would be preferable, but really, normal client apps should just link to a scrollkeeper shared library and avoid the 'dumping out the tree' process with it all just hapenning in memory and not touching disk at all. At least in principle, it should be possible to run in a totaly read-only mode... > Anybody have thoughts? > > Malcolm > Sander There are voices in the street, And the sound of running feet, And they whisper the word -- Revolution! |