On Nov 30, 2007 1:56 PM, Enrico Weigelt <[EMAIL PROTECTED]> 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
