2006-08-20: Keith Bennett dixit: > On Sun, Aug 20, 2006, EV wrote: > > I'd like to discuss another point about restoring fdb. As it > > used to be and it is now, the path DB (libarma_path_db.gz) is > > obtained from the local cache and written back both to the > > cache and as a RK taxi file. I think this is not correct. > > Its management should be homogeneous with that of smalldb. > > That is, the taxi file should be the "master" and the local > > cache should be just that: a local copy of the one in the RK. > > That was the intention. If it doesn't work that way then it is > broken. > > > Once we realize that the management of the Path DB must be > > RK-centered, we should also acknowlwdge that files may go into > > the RK from different computers (this is how I've noticed that > > the Path DB is obtained from the cache, rather than the RK). > > Then there is something wrong with the implementation. If you > look at lk_fdb_load() you will see that it looks for the taxi > file before doing anything else.
I'll test again after applying the new patch. > > Accordingly, if we want to use the Path DB to allow copying > > the RK files back to the dirs they came from when uploaded, I > > think the info in the filedb should include the name of the > > computer. > > I don't think that I agree. I would think that most people > would want to be able to download the contents of the DB file > regardless of what computer they were sat at. If that's not the > case, then it is a bit pointless storing the DB file on the > karma in the first place. We may as well just store it locally. > That would automatically give the behaviour that you want. If you have the computer info in the path DB then you can ignore it for downloading, in the same way as we will surely allow, in fdb-based downlading, to strip the some prefix of the paths. Therefore, this only adds flexibility and costs almost nothing. If the computer info is not stored, then there is no way for figuring out where the tunes came from originally. Another possibility is to allow adding a user-defined prefix to the paths. Ropcp could easyly take care of the option, but I guess something needs to be changed in fdb.c to support that. > > Of course, the contents of the path DB can be useful for > > other things, including a new lkarmafs; so while the origin > > path (and computer) is a good default for the contents for > > each fid, we shold take into account that application > > programs (riocp, lkarmafs, etc.) may want to directly access > > and change the value of this pathname property. So some > > policy is needed regarding contents and format. > > We should cross that bridge when we come to it. My only reason > for re-introducing it is that I wanted an easy way of restoring > the contents of my karma to a previous known state. The current > implementation achieves this goal. Don't understand. How do you use the new fdb functionality for this purpose? Best, EV. ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ linux-karma-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linux-karma-devel
