Drop xattr project idea, it's done

2 files changed, 0 insertions, 48 deletions

diff --git a/community/gsoc/project_ideas.mdwn b/community/gsoc/project_ideas.mdwn
index 4993b01f..c17b06f9 100644
--- a/community/gsoc/project_ideas.mdwn
+++ b/community/gsoc/project_ideas.mdwn
@@ -100,7 +100,6 @@ project_ideas:
   "community/gsoc/project_ideas/virtualization
   community/gsoc/project_ideas/secure_chroot
   community/gsoc/project_ideas/package_manager
-  community/gsoc/project_ideas/xattr
   community/gsoc/project_ideas/driver_glue_code
   community/gsoc/project_ideas/language_bindings
   community/gsoc/project_ideas/file_locking
diff --git a/community/gsoc/project_ideas/xattr.mdwn b/community/gsoc/project_ideas/xattr.mdwn
deleted file mode 100644
index 8e1a532b..00000000
--- a/community/gsoc/project_ideas/xattr.mdwn
+++ /dev/null
@@ -1,47 +0,0 @@
-[[!meta copyright="Copyright © 2009, 2016 Free Software Foundation, Inc."]]
-
-[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
-id="license" text="Permission is granted to copy, distribute and/or modify this
-document under the terms of the GNU Free Documentation License, Version 1.2 or
-any later version published by the Free Software Foundation; with no Invariant
-Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
-is included in the section entitled
-[[GNU Free Documentation License|/fdl]]."]]"""]]
-
-[[!meta title="Implement xattr Support"]]
-
-Extended attributes (xattr) are a standardized, generic method for storing
-additional metadata along with a file (inode). Most modern UNIX filesystems
-support xattrs.
-
-In general, xattrs should be used sparingly, as they are less transparent than
-data stored as explicit file contents; however, there are some cases where they
-really make sense. The Hurd's variant of ext2 presently uses some additional
-fields in the inode to store Hurd-specific metadata: most notable passive
-translator settings. As these fields are Hurd-specific, they can't be accessed
-by the standard methods from Linux for example, so it's not possible to fully
-work with a Hurd filesystem on GNU/Linux (copy, backup etc.); and also, even
-when on Hurd, only tools that explicitly support the Hurd-specific information
-can handle them.
-
-Using extended attributes instead of custom fields for the Hurd-specific
-information would be very helpful.
-
-The most important goal of this project thus is to make the Hurd ext2fs server
-able to store and read the Hurd-specific information with extended attributes
-instead of the custom fields, so it become accessible from other systems. Being
-able to access the information through the standard xattr API instead of
-Hurd-specific calls is also desirable. (And in turn requires implementing the
-generic xattr API first, which can be useful for other purposes as well.)
-
-Completing this project will require digging into some parts of the Hurd, but
-it should be quite doable without previous Hurd experience. Some experience
-with xattrs might help a bit, but shouldn't be really necessary either.
-
-Some previous work on xattr support is [[available|open_issues/xattr]], and
-might serve as a starting point.
-
-Possible mentors: Justus Winter (teythoon), Samuel Thibault (youpi)
-
-Exercise: Implement support for different inode sizes (other than 128 bytes) in
-Hurd's ext2fs.