Hi, as written on the devel list, I'm thinking about adding seek support to file transfers. I'm working on media networks in my PhD thesis and a seekable stream is exactly what I need. First a small scenario why I think it is useful:
I have a media server with a video file. This could either be a storage server for my media files or a record server with the latest recordings I made. Now I want to watch that video. The current approach is to use the file transfer and start watching while the bytes are coming in. This is similar to watching a video file over HTTP. But there are two problems: 1. If it is a recording, I may want to skip the first minutes (recording started to early) or skip the commercials. I don't not like to wait until the file transfer has catched up. 2. Some video container have an (optional) index at the end of the file. To play such a file the player should read the first bytes and the last bytes before starting playback. We also don't want to set up a new stream using SOCKS5 or a future ICE-TCP every time the user seeks (IBB is a stupid idea here, so we ignore it). So we have one stream for the data and should use XMPP stanzas for controlling it. I see two ways of doing it right now, maybe someone has a better idea 1. Add the number of bytes you want to receive on the stream. | Player: send me bytes 0-1023 | File-Server sends the first kb over the data stream | Player: send me bytes 1024-2047 | File-Server sends the second kb over the data stream Well, 1kb may not be a good choice, maybe request 1MB chunks. It is up to the application and use case. Pros: good control over the stream Cons: requires many XMPP messages. 2. Assume that the initiator wants to read the stream like a normal file transfer and add some marks to the stream similar to HTTP chunks: | File-Server sends "0 1024\n" over the data stream | File-Server sends first kb over the data stream | File-Server sends "1024 1024\n" over the data stream | File-Server sends second kb over the data stream | Player sends seek to byte 528743 command, but it takes some time | until that request makes it to the file server | File-Server sends "2048 1024\n" over the data stream | File-Server sends third kb over the data stream | File-Server got the seek request | File-Server sends "528743 1024\n" over the data stream | File-Server sends 1 kb starting from byte 528743 over the data stream HTTP chunks use ASCII for the metadata like stream position, we could replace "1024 1024\n" with a binary struct containing position and length of a chunk. What do you think about that? Should it be part of the Jingle file transfer XEP? If 2. is used, the initiator of the session requesting the stream should be able to turn it off for normal file transfer without the metadata (maybe by setting chunk size to 0). Dirk -- Did you know that dolphins are so intelligent that within only a few weeks of captivity, they can train Americans to stand at the very edge of the pool and throw them fish.
