Generalize direct instantiation of RandomAccessFile to use a File type class instead

[Dan Gravell]

Just a discussion point really...

I've been looking at a few libraries for reading/writing different filesystems other than those natively supported. For example, JCIFS (http://jcifs.samba.org/) provides cross platform CIFS support.

Where these libraries allow random access to files, we should in principle be able to hook JAT into them. In the example above we would be able to read/write tags across CIFS shares.

However, because JAT directly instantiates RandomAccessFile this gets a bit difficult - it couples JAT with the local File implementation.

I wonder if we should generalise AudioFileIO, AudioFileReader and AudioFileWriter to accept more general locators for audio files?

[IJabz]

This sounds similar to a discussion I had some time ago about allowing jaudiotagger to read from streams. Im totally happy that we go with your idea in principle, but I dont have time to work on this myself. What I really want to do is finish AIFF, APE and DSD support we have partial implementations of all three now but none have been completed.

[Dan Gravell]

Agreed. Wouldn't doing it from streams be difficult, or at least sub optimal? Thought you needed some form of random access.

[IJabz]

If instead of passing RandomAccessFiles around we just passed Files around would that solve the issue,Ive just realised that passing RandomAccessFiles rather than Files to AudioFIleReader/Writer is annoying because you dont have access to the original filename, making useful logging difficult.

[Dan Gravell]

I still think Files are too specific. What a "File" means really is a file recognisable by the OS natively, but that's often quite constrained.

Consider CIFS - "File" works in that case on Windows, because Windows has built in support for, say, \\myserver\myshare\file .

But that won't work on Linux. For that you have to use a library, say http://jcifs.samba.org/ . JCIFS does not provide a File - its equivalent is: https://jcifs.samba.org/src/docs/api/jcifs/smb/SmbFile.html . It also provides https://jcifs.samba.org/src/docs/api/jcifs/smb/SmbRandomAccessFile.html to get random access over that object.

Obviously we can't second guess all APIs, so we need some way of providing an adapter between the random access that JAT wants to do and the target.

[IJabz]

Probably but good first step would be to go from RandomAccessFile to File (or Path)

[IJabz]

How does this fit in with NIO Path class, Path is an abstract interface that can be implemented.

[Dan Gravell]

Originally the thrust of this was that RandomAccessFiles should not be directly instantiated, because that is coupled to Java's File concept. So even if we have a bunch of bytes that JAT could work with, it has to be in a file currently.

You can just call toFile on Path to bring you into the File world... I think I misunderstand?

[Silvano Riz]

Hi, this thread is very interesting and it looks like is strictly related to what I was looking for. I've already started a fork where I'm trying to abstract the Readers from the RandomAccessFile. Instead of using Path, I defined an abstract class called DataSource which exposes all the random access operations. At that point everybody could define their own extension of the DataSource. For example I have an InputStream and I will define the InputStreamDataSource. For CIFS you could define the CIFSFileDataSource. The library can also provide some implementations for the common use cases, like FileDataSource or MemoryDataSource. This abstraction is extremely powerful because it enables many more use-cases for the library such as Streaming, using CIFS, possibility to use it with cloud services like Amazon S3, possibility to integrate it in Apache Tika and more.

I'm still working on it, but it would be nice if my work could be integrated with the original and avoid the proliferation of different forks

[IJabz]

Silvano how are you getting on with this ?

[Silvano Riz]

Hi ijabz I did some work and the "read" functionality was almost done. Anyway I didn't have time of finalise my work because I had other priorities at work.

It would be great if you could review the changes I've done until now. I can create a pull request or you could have a look at my fork. What do you think? I just have to merge the mainline into my fork and verify that all the tests are passing.

[IJabz]

Great, a pull request would be most helpful

[Silvano Riz]

Hi ijabz, I can create a pull request alright. Anyway, I think it's better if you create a branch, let say "data-source-generalization", and I create the pull request to merge into that branch and not master. This because I had a lot of conflicts merging your work into my fork and I have unit tests failing. Does it make sense?

[IJabz]

hi, okay Ive added a datasource branch