Mario Ivankovits wrote:
Hi!
I agree that we shouldn't have individual accessors/mutators for
everything that you might want to get
out of a file (i.e. getAuthor, getCreationDate).
What if we had something like this:
MetadataFactory
[org.apache.commons.vfs.metadata]
+ static getMetadata(FileObject file):Map
+ static getKeys(FileObject file):Set
Does this mean we have to deal with untyped informations?
I mean we have to do something like getMetadata(fo).get("TITLE") ?
This is something I would avoid in any case.
What do you mean by "untyped informations"? I was thinking of a map of
Strings (Map<String, String>). Were there other
types that you were thinking about supporting? Dates and numbers can be
easily converted from Strings to those types, and we can either provide
some assistance there with helper methods, or let the user do it.
Is there some reason that you say you would "avoid in any case"?
I've found that if users can't find something within 5-10 minutes they
figure it's not there, and either give up on the API or write their
own. Neither of which we would want them to do.
The trick is getting them to "step into" the service API to begin with
-- it would require them to think of metadata as a service. It's not
something that naturally occurs to people to do and so they would
probably never think to look in a services package for metadata code.
This is why the name "service" is no longer on top of my list. Currently
its "operation", but thinking of it would show me that "aspect" is more
correct.
I think aspect would be confusing since people would think that you were
adding AOP functionality to VFS.
It isn't a new concept; however, its implementation in JAF left a lot
to be desired, and was difficult for a lot of people to understand.
This is the primary reason that it doesn't really get used a lot.
It's still gives me headaches when I look at the doc on it. :-)
An org.apache.commons.vfs.metadata package would be fairly obvious to
most people.
Yes, this is something we would like to have anyway.
In this package we will find something like
org.apache.commons.vfs.aspects
.vcs.Update
.vcs.Commit
.vcs.Lock
.....
.info.FileInfo
.image.Thumbnail
most of the above will only be a interface (or abstract class) with
concrete implementations for SVN, CVS, OO, MS Office, JPG, and so on
(maybe outside of this
e.g
org.apache.commons.vfs.aspects.impl.svn.SvnUpdate
org.apache.commons.vfs.aspects.impl.svn.SvnCommit
It might be better to keep all of the provider code in the same provider
package. (i.e. org.apache.commons.vfs.provider.svn.commands
org.apache.commons.vfs.provider.sftp.commands
Your .image.Thumbnail reminded me that it might be better to have a more
generic way of saying this. Perhaps ".info.Preview". The reason being
that the movies have a preview image, sound files can have a preview
clip and images can have Thumbnails.
All of which are good. But most people only check them after they
haven't been able to find it in the Javadocs under some intuitive
package name. :-)
You are right, I am one of them ;-)
Is the DocumentInfo some other interface you're thinking of? If so,
what's the difference between FileContentInfo and DocumentInfo?
Yes, maybe no difference, only that the service API will provide a more
generalized and cleaner way to deal with the various requirements.
Are you anticipating that you'll have some sort of "service discovery
" mechanism that will automatically register all services found in the
classpath and make them available? If so, then this too would require
some work to make it easy for users to use. There would need to be
some mechanism for the user to install supporting JARs needed for
specific metadata service providers.
VFS already uses a plugin mechanism by scanning the classpath and
processing all META-INF/vfs-providers.xml - so the user has nothing more
to do then to drop in the JAR.
Cool. But if everything is implemented that way then it becomes a
nightmare to build because every plugin will have it's own build target,
or separate build file and jar file -- won't it?
I believe that most of what I've outlined though, is so standard and
generic that it should be part of the standard VFS distribution rather
than available through additional downloads.
Users already rant about the size of the current VFS jar and told me not
to pack all in one jar. This is why I created the plugin discovery.
I think usually people want and expect everything in a single
download, rather than having to make choices about which service
providers they want.
I also like the single download approach, but as I said, others dont.
And ....
I guess one way to satisfy everybody would be to provide a "core"
distribution and a "complete" distribution.
The existing file system service providers are a good example of
this. Right now you have to explicitly download and install
additional jars to get the some of functionality that you want.
.... is only a matter of time this will change. ie. I cant add the SVN
services to VFS core as the used library (JavaSVN) uses a non ASF
compatible license.
This is true for a requested filesystem implementation (novell) too.
In fact, that's probably a good way to split things up. Anything that
is fairly common (metadata for images, movies, sound, office files) can
be implemented under the current Apache license should be part of the
core distribution. Anything that requires a library that doesn't meet
the ASF license, can be downloaded in the same way that you do with the
current "get-dep*" targets in the build file. This should keep the file
size rather small, and would still give people the flexibility that they
want.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
