I/O stream design

[Andrey Kiselev]

Hi folks,

I am trying to understand the idea of opj_cio object. It looks a bit
strange to me. Typically such things look like that:

typedef stream_handle void*;

typedef struct {
stream_handle handle;

(ssize_t *read)(stream_handle handle, void *buf, size_t count);
(ssize_t *write)(stream_handle handle, void *buf, size_t count);
(off_t *seek)(stream_handle handle, off_t offset, int whence);
(off_t *tell)(stream_handle handle);
} stream_t;

and stream_read()/stream_write() functions are just a wrappers around
default or user supplied r/w routines. This way user has a possibility
to override the default read/write/seek functions with his own
implementations, providing either in-memory buffer filled with the
data or read them directly from disk or network socket. Is it possible
to refactor the current opj_cio implementation into that kind of
object? I am ready to work on that and supply the patch.

Another related question: why opj_cio_open() needs codec context
object as an input? My understanding that opj_cio_open() should just
construct a stream object from the user's data (buffer address, file
name etc.) and it has nothing to do with the codec, which should be
associated with the stream later opj_decode()/opj_encode() functions.

Best regards,
Andrey

--
Andrey V. Kiselev
ICQ# 26871517

[François-Olivier Devaux]

Andrey Kiselev a écrit :

> Hi folks,
>
> I am trying to understand the idea of opj_cio object. It looks a bit
> strange to me. Typically such things look like that:
>
> typedef stream_handle void*;
>
> typedef struct {
> stream_handle handle;
>
> (ssize_t *read)(stream_handle handle, void *buf, size_t count);
> (ssize_t *write)(stream_handle handle, void *buf, size_t count);
> (off_t *seek)(stream_handle handle, off_t offset, int whence);
> (off_t *tell)(stream_handle handle);
> } stream_t;
>
> and stream_read()/stream_write() functions are just a wrappers around
> default or user supplied r/w routines. This way user has a possibility
> to override the default read/write/seek functions with his own
> implementations, providing either in-memory buffer filled with the
> data or read them directly from disk or network socket. Is it possible
> to refactor the current opj_cio implementation into that kind of
> object? I am ready to work on that and supply the patch.
>

Hi Andrey,

Indeed, the streaming handling of version 1.3 was quite a limitation to
the library. It has been modified in a similar way as you suggest in
version 2.0 (stage alpha ;-)).

François

[Andrey Kiselev]

François,

On Fri, Feb 29, 2008 at 2:51 PM, François-Olivier Devaux
<francoi...@uclouvain.be> wrote:
> Indeed, the streaming handling of version 1.3 was quite a limitation to
> the library. It has been modified in a similar way as you suggest in
> version 2.0 (stage alpha ;-)).

Sounds good! Is it possible to get the 2.0 branch from SVN?

[Pierre Joye]

Hi François,

On Fri, Feb 29, 2008 at 1:08 PM, Andrey Kiselev
<andrey....@gmail.com> wrote:
>
> François,
>
>
> On Fri, Feb 29, 2008 at 2:51 PM, François-Olivier Devaux
> <francoi...@uclouvain.be> wrote:
> > Indeed, the streaming handling of version 1.3 was quite a limitation to
> > the library. It has been modified in a similar way as you suggest in
> > version 2.0 (stage alpha ;-)).
>
> Sounds good! Is it possible to get the 2.0 branch from SVN?

Working on a GD support for your great library, I would also be very
interested in the 2.0 branch. I think it may make more sense to target
2.0 instead of 1.3, depending of the dead lines you have for a stable
2.x release :)

Best regards,
--
Pierre
http://blog.thepimp.net | http://www.libgd.org