Re: Proposal for metadata interoperability on OS X
Re: Proposal for metadata interoperability on OS X
- Subject: Re: Proposal for metadata interoperability on OS X
- From: Tom Andersen <email@hidden>
- Date: Tue, 08 Jul 2008 11:20:27 -0400
As I said, all numbers are fanciful. I just wanted to get a discussion
started.
From our point of view I would prefer a much much smaller limit.
There needs to be limits so that we can design interface around these
attributes, and it seems also for technical reasons on the size of an
attribute. I think that the way to go about this is to talk this back
and forth here for a bit, then have someone go and write some code to
implement the guidelines and turn them into a nice cocoa api. For
instance, one thing that I run into with tags is that some programs/
users enter (say 6) tags as a comma delimited string, and this gets
stored as a single string in an array of length one. It's not
impossible to catch this sort of thing and deal with it, but if it
were all in one open sourced class, it would be a lot easier and more
consistent.
Suggested Fields
---------------
Tags
Authors
URLs
Character encoding for text files
Checksum
+ application defined?
It seems like a small well defined set of attributes to use would be
better than a larger set. At least as a first step.
Where are the maximum xattr lengths documented? I read on a wiki page
that HFS+ limits xattrs to 'one b-tree node' which I take it is 4k.
http://en.wikipedia.org/wiki/Extended_file_attributes
--Tom
On 8-Jul-08, at 10:59 AM, Mac QA wrote:
On Tue, Jul 8, 2008 at 10:45 AM, Tom Andersen <email@hidden>
wrote:
User Entered tags:
--------------------------
stored: under the keyword: kXATTR_UserTags
value: NSArray of NSStrings. No hierarchy, maximum tag length 100
chars,
maximum number of tags 100, Guidelines: tags should be entered by
the user,
and not be things like GUIDs, paths, etc.
You want all of this in one extended attribute? Even assuming no
overhead for NSArray or NSStrings, wouldn't 100 chars/tag * 100 tags
already be about 2-3 times the maximum amount of storage currently
allowed in one generic extended attribute? As I understand the maximum
is roughly 4K, with the ResourceFork being a special case clearly.
On 8-Jul-08, at 10:59 AM, Mac QA wrote:
On Tue, Jul 8, 2008 at 10:45 AM, Tom Andersen <email@hidden>
wrote:
User Entered tags:
--------------------------
stored: under the keyword: kXATTR_UserTags
value: NSArray of NSStrings. No hierarchy, maximum tag length 100
chars,
maximum number of tags 100, Guidelines: tags should be entered by
the user,
and not be things like GUIDs, paths, etc.
You want all of this in one extended attribute? Even assuming no
overhead for NSArray or NSStrings, wouldn't 100 chars/tag * 100 tags
already be about 2-3 times the maximum amount of storage currently
allowed in one generic extended attribute? As I understand the maximum
is roughly 4K, with the ResourceFork being a special case clearly.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden