[File-extattr-commits] File-ExtAttr TODO,1.17,1.18

[Richard D. <ric...@us...>]

Update of /cvsroot/file-extattr/File-ExtAttr
In directory sc8-pr-cvs17.sourceforge.net:/tmp/cvs-serv19867

Modified Files:
	TODO 
Log Message:
Reformat todo list; expand on exceptions todo; remove stuff about renaming the module

Index: TODO
===================================================================
RCS file: /cvsroot/file-extattr/File-ExtAttr/TODO,v
retrieving revision 1.17
retrieving revision 1.18
diff -C2 -d -r1.17 -r1.18
*** TODO	4 Jul 2007 10:08:29 -0000	1.17
--- TODO	26 Jan 2008 08:38:11 -0000	1.18
***************
*** 1,97 ****
  todo:
! utf8
! warnings
! check that partition supports it, especially in unit test
! docs, explain user_xattr, mount -o remount
! change to use section 2 calls instead of section 3
! for "operation not supported" note must be prefixed with "user"
! buffer size, reuse buffer?
! throw exceptions rather than warnings on getxattr() failure
! symbolic link handling (O_NOFOLLOW on Mac OS X)
! Check it can be used with Perl 5.6.x
! Test setting attributes on directories, as suggested at Brum.pm
! Factor out common code from the tests
! Refactor the buffer allocation into a common function in ExtAttr.xs
! 
! Remove dependency on libattr on Linux - just define ENOATTR -> ENODATA?
! (Feels a bit evil to do that.)
! 
! Unite somehow with File::Attributes (which is for file systems
! without xattrs)?
! 
! Document pre-reqs for test suite: Test::Distribution, Test::Pod::Coverage,
! Test::YAML::Meta. Include these in a .spec file that we can include
! with distro
! 
! Disallow nuls in the attribute names. The list handling will break
! if we allow this. (Alternative is to make the portable listxattr follow
! the BSD API, where the separator is a length byte.)
! 
! Rename the module?
! ~~~~~~~~~~~~~~~~~~
! 
! Or could we just mention "metadata" in the one-line summary
! for File::ExtAttr? Then people searching for metadata, extattr, xattr
! would likely find the module. Actually, test whether those terms find
! the module /already/.
! 
! My reply to brian d foy's mail:
! 
! "brian d foy wrote:
! 
! > [[ This message was both posted and mailed: see
! >    the "To," "Cc," and "Newsgroups" headers for details. ]]
! >
! > In article <200...@pa...>, Perl Authors
! > Upload Server <up...@pa...> wrote:
! >
! >
! >>  modid:       File::ExtAttr
! >>  DSLIP:       cmcfp
! >>  description: Access extended attributes of files
! >
! >
! >
! > How about File::Attributes::Extended or something like that? The "Ext"
! > abbreviation is vague.
! 
! 
! What else would go under File::Attributes::*? I couldn't think
! of anything else that would reasonably go in that namespace.
! Is it worth creating a namespace for just this module?
! 
! The original motivation for this name was that extended attributes
! are known as "extattrs" (*BSD) or "xattrs" (Linux).
! 
! > You might also take a look at File::Spec to see how it handles
! > multi-platform support and names the various bits. :)
! 
! Thanks.
! 
! We (Kevin Goess and I) discussed having a submodule per platform,
! but we decided to do have all the cross-platform in the XS.
! Haven't /actually/ tried that yet, though. ;)"
  
! Steffan Mueller's mail:
  
! "Richard Dawe wrote:
! >> How about File::Attributes::Extended or something like that? The "Ext"
! >> abbreviation is vague.
! >
! >
! > What else would go under File::Attributes::*? I couldn't think
! > of anything else that would reasonably go in that namespace.
! > Is it worth creating a namespace for just this module?
! >
! > The original motivation for this name was that extended attributes
! > are known as "extattrs" (*BSD) or "xattrs" (Linux).
  
! There is File::Attribute. It does something similar
! but in a completely different way. It creates .filename.attributename files
! to store the attribute data.
  
! I wouldn't use the File::ExtAttr name either since it's too cryptic.
! Personally, I was well aware that different OS's and file systems support
! per-file meta data, but I didn't know what it was called. If I searched CPAN
! for that functionality, I'd look for File::MetaData or File::Atribute(s),
! but I would probably miss File::ExtAddr."
--- 1,29 ----
  todo:
! * utf8
! * warnings
! * check that partition supports it, especially in unit test
! * docs, explain user_xattr, mount -o remount
! * change to use section 2 calls instead of section 3
! * for "operation not supported" note must be prefixed with "user"
! * buffer size, reuse buffer?
! * throw exceptions rather than warnings on getxattr() failure
!     (set $@, die => need eval to catch errors? not sure I like that)
! * symbolic link handling (O_NOFOLLOW on Mac OS X)
! * Check it can be used with Perl 5.6.x
! * Test setting attributes on directories, as suggested at Brum.pm
! * Factor out common code from the tests
! * Refactor the buffer allocation into a common function in ExtAttr.xs
  
! * Remove dependency on libattr on Linux - just define ENOATTR -> ENODATA?
!   (Feels a bit evil to do that.)
  
! * Unite somehow with File::Attributes (which is for file systems
!   without xattrs)?
  
! * Document pre-reqs for test suite: Test::Distribution, Test::Pod::Coverage,
!   Test::YAML::Meta. Include these in a .spec file that we can include
!   with distro
  
! * Disallow nuls in the attribute names. The list handling will break
!   if we allow this. (Alternative is to make the portable listxattr follow
!   the BSD API, where the separator is a length byte.)