From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <140e7ec30712030008u4bbcdf1fybc1474c999b72cf6@mail.gmail.com> Date: Mon, 3 Dec 2007 17:08:10 +0900 From: sqweek To: "Fans of the OS Plan 9 from Bell Labs" <9fans@cse.psu.edu> Subject: Re: [9fans] Storing bookmarks+history w/ 9P In-Reply-To: <20071130045601.GB2817@nibiru.local> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20071130045601.GB2817@nibiru.local> Topicbox-Message-UUID: 10ea32d8-ead3-11e9-9d60-3106f5b1d025 On Nov 30, 2007 1:56 PM, Enrico Weigelt wrote: > I already wrote some ideas for storing browser bookmarks and > history via an synthetic filesystem some time ago. > > Here's a little wiki page about this: > > http://oss-qm.metux.de/index.php/9forge/bookmarkfs Hm. My knowledge of 9P is worse than I would like, so I don't have a good idea of what makes sense to implement. Nor do I have a lot of experience with synthetic file servers to know what works and what doesn't. But, I suspect you're focusing a bit too much on existing interface, rather than simplicity and the "right" approach. Putting a .bookmark extension on every file seems excessive for an fs that essentially only contains directories and bookmarks. Also, the actual filename doesn't appear to be used for anything - so judging by Mozilla's past, if such an interface is adopted by Gecko you'll get B84E21AC.bookmark, A8BF4371.bookmark, etc etc. What if the filename corresponded to the bookmark name, and do you really need a description field? If you dropped it, you'd have filename <=> bookmark name, mtime <=> last visited, file contents <=> url. It maps better to history entries also, which certainly don't have descriptions. /history/by-proto-date-hostname/date essentially corresponds to an "ls -rt /history", /history/by-proto-date-hostname/hostname is just "cat /history/* |sort". Though considering how many entries you'll have, I wonder if a file per history entry is even a sensible approach here. A flat file with two columns(DATE HOSTNAME) does pretty much the same job with less overhead/clutter... -sqweek