filesystem.attributes potentially could be a pain for users, since it hides some information in a binary format; cf. plans to use XML for .form files.

Suggestions:

- have DefaultAttributes store attributes in a partially text format. Would just need to make DefaultAttributes.Table externalizable, I guess, and implement it. E.g.:

foo.java:NbWhateverAttribute=Lcom.netbeans.ide.execution.ProcessExecutor;<DEADBEEFCAFEBABE>
foo.gif:NbAnotherAttr=Lcom.netbeans.impl.FooClass;[<FEED666BEE>

I.e. first file name with suffix, `:`, attribute name as string, `=`, name of class of attribute in VM format (ignored when reading--informational only, so users can get an idea of what is there if th
ey must), `<`, hex escape of serialized form, `>`, newline.

At least this would allow users to kill lines they knew were corrupting something, without wrecking all the other attributes. E.g. if an uninstalled module left attributes corresponding to unavailable
 classes. Using an explicit line-by-line read would also allow the DefaultAttributes impl to ignore any lines which could not be correctly deserialized, a nice side effect.

- make sure that VC filesystems are able to keep track of attributes somehow, if this is not already the case. Maybe they shouldn`t--then each checked-out copy of a filesystem would need to have thing
s like the executor set from scratch, though. Could be an option. If they are stored, a text format like suggested for DefaultAttributes should probably be used.


[Jarda says XML format possible, but super-slow]