On Fri, Oct 15, 2010 at 8:24 AM, Mladen Turk <mt...@apache.org> wrote:
> On 10/15/2010 04:57 PM, Costin Manolache wrote: > >> Are you going to replace DirContext ? >> >> If yes - great, but please first send a quick summary comparing your API >> with the other VFS >> around in apache. I think commons has few targets, including a hdfs, I >> remember there are more. >> >> > Well it's not a VFS, and it doesn't have an API. > The API is java.io + java.util.zio with o.a.t.vfs namespace > instead java.io > (Frankly didn't came up to the DirContext in experiment, > but it shouldn't be any different then others) > > I'm not very comfortable with another layer below DirContext... Big +1 if you get rid of DirContext and replace it with your File. I did an experiment in lite - it is not very hard actually to replace DirContext with raw File. The main problem was that java.io - like DirContext - is an old and not very fit API, lot of cruft, blocking, etc. In any case - having a summary of the other VFS APIs would help a lot. Is there any existing API that support non-blocking access to files / streams ? Costin > So the o.a.t.vfs.File is java.io.File in case the provider > in "transparent". In case it's "raw" (Those names are mine) > the File is o.a.t.vfs.providers.raw.File which only makes > sure that it doesn't cross the "root" mount point. > > The point here is that provider *can* use commons vfs, > and that's the idea, but then again the Hadoop's hdfs has a > descent API on it's own. > > > > Regards > -- > ^TM > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
