Serves you right for posting Slashdot questions. Before reading your clarification, I prepared this:
----
I don't understand your goal exactly. Is it:
A. To use the libraries for locating and parsing the ID3 tag. You trust them to consume data efficiently, and the problem is just how to encapsulate file access over HTTP.
B. You can use your own code to locate and fetch the ID3 tag, and you wish to use the libraries to parse it. For this you could embed the tag in a fake local MP3 file. Does that need to be the same size as the original, and if so do you need some kind of sparse file support.
C. You need to write new code to locate and parse the ID3 tag while consuming data efficiently (the libraries read too eagerly). you would like to make your code part of the libraries, but architectural considerations make this hard.
for A and B (with sparse files) you need some sort of loopback device, to implement HTTP encapsulation or sparse files. Both of these sound like they could have general use. Is the problem that they require root access?
In that case could a socket (on the filesystem) be an alternative? I don't know if they can be seekable and if your libraries require that. But if you trust the libraries to read once and only seek forward, you could probably implement the appropriate sockets.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
timeasmymeasure
no subject
Date: 2004-05-19 08:44 pm (UTC)----
I don't understand your goal exactly. Is it:
A. To use the libraries for locating and parsing the ID3 tag. You trust them to consume data efficiently, and the problem is just how to encapsulate file access over HTTP.
B. You can use your own code to locate and fetch the ID3 tag, and you wish to use the libraries to parse it. For this you could embed the tag in a fake local MP3 file. Does that need to be the same size as the original, and if so do you need some kind of sparse file support.
C. You need to write new code to locate and parse the ID3 tag while consuming data efficiently (the libraries read too eagerly). you would like to make your code part of the libraries, but architectural considerations make this hard.
for A and B (with sparse files) you need some sort of loopback device, to implement HTTP encapsulation or sparse files. Both of these sound like they could have general use. Is the problem that they require root access?
In that case could a socket (on the filesystem) be an alternative? I don't know if they can be seekable and if your libraries require that. But if you trust the libraries to read once and only seek forward, you could probably implement the appropriate sockets.
----
Pavlos