Mailing-List: contact commons-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Users List" <commons-user@jakarta.apache.org>
Received-SPF: pass (asf.osuosl.org: domain of mario@ops.co.at designates
 194.152.182.4 as permitted sender)
Message-ID: <43F43341.9030901@ops.co.at>
Date: Thu, 16 Feb 2006 09:09:37 +0100
From: Mario Ivankovits <mario@ops.co.at>
User-Agent: Thunderbird 1.5 (X11/20060111)
MIME-Version: 1.0
To: Jakarta Commons Users List <commons-user@jakarta.apache.org>
Subject: Re: [vfs] File Metadata
References: <43F24392.7060701@yahoo.com> <43F2DA1B.50903@ops.co.at>
 <43F337C4.9060401@yahoo.com> <43F33D06.7040808@ops.co.at>
 <43F357E6.7090602@yahoo.com> <43F35C2B.4070002@ops.co.at>
 <43F377C7.1090802@yahoo.com>
In-Reply-To: <43F377C7.1090802@yahoo.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

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.

> 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.

> 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
 
> 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.

> 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 ....

> 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.

> It would be easier, if everything you needed to get started were
> available in a single download, or with a single Ant "install" target.
I know what you mean - unhappily sometimes live isnt that easy ;-)


Ciao,
Mario


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org