Summary: | API: EFS should support generic file properties | ||||||
---|---|---|---|---|---|---|---|
Product: | [Eclipse Project] Platform | Reporter: | Martin Oberhuber <mober.at+eclipse> | ||||
Component: | Resources | Assignee: | Platform-Resources-Inbox <platform-resources-inbox> | ||||
Status: | NEW --- | QA Contact: | |||||
Severity: | enhancement | ||||||
Priority: | P3 | CC: | alex.blewitt, corneanu_dan, david_williams, eclipse, g.watson, john.arthorne, Michael.Valenta, mtstorm | ||||
Version: | 3.3 | ||||||
Target Milestone: | --- | ||||||
Hardware: | All | ||||||
OS: | All | ||||||
Whiteboard: | |||||||
Attachments: |
|
Description
Martin Oberhuber
2007-03-01 11:43:36 EST
Created attachment 60092 [details]
Patch to add generic file properties to EFS
Attached patch provides generic file properties for EFS.
Some basic design considerations:
* Existing int/String API is fully preserved but marked deprecated. The patch
should be fully compatible with Eclipse 3.3M5.
* Properties are associated with IFileInfo rather than IFileStore since clients
may choose to read properties or not need them for other applications.
Existing IFileStore.fetchInfo() implementations work very well for this.
An improved implementation could define an options flag for fetchInfo() to
specify whether just the "quick and easy" properties should be retrieved
(similar to SHALLOW) or also "more time consuming ones" (similar to DEEP).
Also, IFileStore.equals() should depend on the file store's name alone but
not any properties.
* For the property key, a new interface (IFilePropertyType) is introduced.
This allows for equals() and hashCode() implementations, and provides
meta-info that can be extended in the future.
The meta-info includes type information, which is currently only for
informational purpose and not being checked in the providers.
* Rather than limiting FileInfo not to be subclassed by clients, this is now
allowed because the file system providers are the only ones who know how
their file information can be stored most efficiently. They are now allowed
to derive from FileInfo in order to provide their special implementation.
By allowing extenders to register their own file properties which are
identified by a String (reverse DNS notation recommended), it is possible
for anyone to register their own file properties. Plus, file system providers
can be compatble with each other just by supporting file properties with the
same ID and type even if they do not have to share a common interface.
Just wondering, do you want to keep the int-based EFS Properties for M6 or get rid of them again? Although I like my attached patch a lot - after a long talk I had with Michael Valenta at EclipseCon, I'm easy with anything, since there's good arguments for all alternatives. * Keeping the int-based Properties API would allow passing the symbolic link target (which I don't consider particularly helpful) or a unique file ID that could be derived from UNIX inode numbers (which might be more helpful as a high-performance alternative for File.getCanonicalPath() e.g. in bug 105554). * On the other hand, I consider the int-based properties still somewhat awkward in case one wants to extend them in the future... but even that could be solved with a utility class that generates new unique integer numbers for arbitrary passed-in IDs. * For the concrete case of symbolic links, it's more important to know that something actually is a symbolic link (boolean attribute) than knowing the link target; since properly resolving a link target is only possible on the concrete target filesystem, it's not of much value except informational. In any case, providers who think they _have to_ do special properties can always derive from FileInfo and do their own thing (yes I know the API discourages that, but it's not impossible). So even though I like my attached generic patch here a lot, I'm fine with not using it and either keeping the int-based properties or getting rid of them and staying with boolean-only properties. PS In case time is an issue, it might be an option to deprecate the get/setStringAttribute() API for M6 and decide on getting rid of it or keeping it for M7? The API will be frozen for M6 - deleting API in M7 is not possible. I am inclined to keep the API we have. Here is another suggestion for M6: Keep the current functionality, but move it out of API and into internal packages. Affected items would be: package org.eclipse.core.internal.filesystem; public interface IFileInfo2 extends IFileInfo { public static final int ATTRIBUTE_LINK_TARGET = 1 << 6; public abstract String getStringAttribute(int attribute); } package org.eclipse.core.internal.filesystem.local; public class LocalFileInfo extends FileInfo implements IFileInfo2 { public String getStringAttribute(int attribute) { /* ... */ } public void setStringAttribute(int attribute, String value) { /* ... */ } } So we could still use and experiment with the functionality, keep current native libraries as they are, but have it out of API for 3.3. People who think they need it could use it from the internal package. If you are interested, I could put together a patch for this. I'm working on the EFS-editor and I would like to see the J2EE-Web like context idea. java.lang.Object getAttribute(java.lang.String name); java.util.Enumeration getAttributeNames(); void setAttribute(java.lang.String name,java.lang.Object o); void removeAttribute(java.lang.String name); I realy need them for the editor so a user can select what he wishes to see, and the EFS provider can give the correct attributes. I realy hope this will be adapted. Please select for the attributes values Object in stead of a String. This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. |