Hi all, I am evaluating the performance and suitability of jackrabbit as a store for media (as in big movies).
We have some specific requirements: * media needs to be accessed by native components via filesystem, dav, http or a similar solution * On the JCR side, media getStream() needs to be seekable, or similarly Binary.read(byte[], long) needs to seek and not read the whole file * we need to connect to repository via network ( For what I'm seeing with last stable release (2.6.3) and current unstable (2.7.1) in some simple tests, getStream or Binary.read reads the whole file in and later select. Also I'm seeing unstability and errors in the use of jackrabbit as a DAV server with gnome gvfs (ubuntu 13.04 is deeply broken) or even mount.davfs. I would have expected that a technology so mature and used for big size files (video, audio, documents) would use "content-length"/accept-ranges"/"content-range" headers to implement seekability in DAV or pure HTTP, both in the jackrabbit and the linux sides (libneon, basically), and also that the Binary.read implementation would use them, but this is not the behavior I'm seeing, either in the JCR side or the OS/DAV side. I'm puzzled. Any pointers to resources describing the status of the field WRT seekability of JCR file resources with different backends? Googling extensively is not delivering any meaningful result. Regards Santiago
