From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Wed, 5 Dec 2007 12:02:22 +0100 From: Enrico Weigelt To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu> Subject: Re: [9fans] Storing bookmarks+history w/ 9P Message-ID: <20071205110221.GA24989@nibiru.local> References: <20071130045601.GB2817@nibiru.local> <140e7ec30712030008u4bbcdf1fybc1474c999b72cf6@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <140e7ec30712030008u4bbcdf1fybc1474c999b72cf6@mail.gmail.com> User-Agent: Mutt/1.4.1i Topicbox-Message-UUID: 11eb84a2-ead3-11e9-9d60-3106f5b1d025 * sqweek wrote: Hi, > 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. Well, the idea behind is the classification of the actual file. Of course an subdirectory means an folder, but every folder may have several kind of data, bookmarks and folder metadata. Some attributes could be done directly within the fs (eg mtime), but others cannot. So do you have an better solution ? > What if the filename corresponded to the bookmark name, and do you > really need a description field? The description is not the name, but an additional (longer) descriptive text. Maybe we want to add some more things, eg. tags later. I don't want to invent an new fs for that ;-o > If you dropped it, you'd have filename <=> bookmark name, mtime <=> > last visited, file contents <=> url. Yes, that would work, but we'd loose the ability to assign more information (eg. additional descriptions, tags, etc) to the bookmarks. I don't think having and propertylist instead of just the url as content would be that bad. Ah, and are you sure about that the mtime should be really the last-visited time istead of the time the bookmark was really changed ? (BTW: does 9P support atime's ?) > It maps better to history entries also, which certainly don't > have descriptions. Right, history doesnt need such metas. But history is some bit special. On my first ideas history was completely out, just while writing the wiki page I had the idea to put it in here. Having bookmarks and history in one fs allows to make things simpler and more efficient for the client: the client simply sends an TOUCH command to the server, and the server is responsible for updating the proper records (eg. add an new journal entry, update existing bookmarks pointing to the same url, etc). > /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... Well, these are just several views to the (large) journal. Please keep in mind, the journal can be quite large. You're right, an flat file might do better for some cases. But there still should be different views, eg. per host, etc, so the client doesn't need to download the whole journal every time. BTW: 99% of the journal access will be: a) touch an url b) check whether the url has been seen IMHO this should go through the ctl interface. cu -- --------------------------------------------------------------------- Enrico Weigelt == metux IT service - http://www.metux.de/ --------------------------------------------------------------------- Please visit the OpenSource QM Taskforce: http://wiki.metux.de/public/OpenSource_QM_Taskforce Patches / Fixes for a lot dozens of packages in dozens of versions: http://patches.metux.de/ ---------------------------------------------------------------------