* Re: [9fans] Storing bookmarks+history w/ 9P
2007-12-03 8:08 ` sqweek
@ 2007-12-05 11:02 ` Enrico Weigelt
0 siblings, 0 replies; 3+ messages in thread
From: Enrico Weigelt @ 2007-12-05 11:02 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs
* sqweek <sqweek@gmail.com> 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/
---------------------------------------------------------------------
^ permalink raw reply [flat|nested] 3+ messages in thread