On Nov 7, 2007 5:53 PM, Torsten Curdt <[EMAIL PROTECTED]> wrote:
>
>
> On 07.11.2007, at 04:54, Niall Pemberton wrote:
>
> > On Oct 21, 2007 7:12 AM, Mario Ivankovits <[EMAIL PROTECTED]> wrote:
> >> Hi!
> >>
> >>>> Maybe it would make more sense to do these changes in commons-
> >>>> jci-fam
> >>>> first and then move that to a new commons-fam?
> >>>>
> >>>
> >>> Sounds reasonable, although I still think IO is a better home for
> >>> fam
> >>> than a separate component.
> >> In any case, it would be creat if the code is built in a way that
> >> makes
> >> it possible to plug VFS in there too. The VFS fam is far from being
> >> perfect :-(
> >
> > I'm not sure how this would be possible - since we would need to
> > abstract away from java.io.File - which is exactly what VFS does. For
> > me theres value in a "closer to the metal" impl. that just deals with
> > java.io.File and an abstract VFS version.
>
>
> Well, one thought would be to use generics. The JCI monitor expects a
> very simple interface that both the native java.io.File and the VFS
> abstraction share. (see FilesystemAlterationObserverImpl.MonitorFile)
>
> private interface MonitorFile {
> long lastModified();
> MonitorFile[] listFiles();
> boolean isDirectory();
> boolean exists();
> String getName();
> }
>
> The problem here is that in java you need to explicitly implement an
> interface to be compatible with the interface (not just implement the
> methods described through it). So while this would work
>
> public FilesystemAlterationListener<E extends MonitorFile> {
> onFileChange(E file)
> ...
> }
>
> public class FAM<E extends MonitorFile> {
> ...
> }
>
> and VFS could just implement the MonitorFile
> interface ...java.io.File cannot (although it actually does). I fear
> the only way to share the same code would be
>
> a) through reflection
> b) have VFS extend the java.io.File class. But I guess we already
> agreed in the "compress" thread that is not really a good idea.
> c) use the interface in the Listener
>
> public FilesystemAlterationListener<E extends MonitorFile> {
> onFileChange(MonitorFile file) {
> File f = (File) file.getImpl(); // UGLY!!
> }
> ...
> }
>
> but that sucks as you cannot get to the actual implementation
> easily.
>
>
> Thoughts?
Since VFS's FileObject[1] is already an abstraction which includes a
java.io.File implementation it doesn't make alot of sense to me to
then layer another level of abstraction on top of that so that fam can
work with either java.io.File or o.a.c.v.FileObject. I'm sure
something could be designed/built to cater for both but IMO its not
desirable - if that is the aim then better to just provide fam for VFS
which would provide fam for the local file system as well. Personally
I think theres value in both - i.e. fam functionality in VFS for
people who are happy with its layer of abstraction and want the
uniformity whatever the file system being monitored and fam
functionality for java.io.File that is straight forward to understand
for those that only interested in the local file system and can
utilise e.g.the standard java.io.FileFilter to refine whats being
monitored.
So IMO none of the 3 options above provide a good solution and better
IMO to have two implementations (one for VSF and one for
java.io.File).
Niall
[1] http://commons.apache.org/vfs/apidocs/org/apache/commons/vfs/FileObject.html
> cheers
> --
> Torsten
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
