[CREATE] libora goals, use-cases and API

[Luka Čehovin]

> Ok, then our goals might be different.

Excellent that we found this out now and not in a month or two :)

> What are your concrete goals
> for libora, that is:
> which problems do you want to solve with libora (and which problems do
> you not want to)?

I would like to provide a library that takes away the fiddling with
zip archive, png compression and that stuff. But the idea was that it
should not provide infrastructure to actually keep the data in memory
and manipulate it as an application can do this more efficiently and
(more important) in its own way. My focus was just on loading and
storing data by stack traversal. Nothing else.

But it is logical that it does not have to end here. As I have said a
high level wrapper can be made (a c++ one even) that would allow a
more object-oriented access (using more memory perhaps but that makes
sense here).

> Or, asked in another way, what are the intended use-cases for libora?

- Well one simple use case is displaying a thumbnail for some preview
application: for this reason I created a flag that disables loading of
the stack so an application can just leave that and only accesses the
thumbnail raster (if it exists).
- The other use case that is not yet implemented is loading all the
layers in an application that uses tile structure. In that case a
special function would load the image via callbacks that would supply
individual tiles ... similar for saving. The idea is that since we
have a direct access to low level libpng we do not have to render an
entire layer in an image but supply individual tiles that are then
stitched together on the fly.
- And of course everything in between. But my idea is to first provide
access to the "raw" data and then perhaps extend the library with
functionality like rendering a combined image and such. But the way I
see it a lot of potential users would not use that because they have
their own solutions already or they plan to solve this high end stuff
in their own way ... so all I want to give them is a way to write data
in a standard way without bothering with the details.

Btw: do you need more documentation? Perhaps some inline comments
where the code is a bit confusing?

-- 
Luka Čehovin
http://luka.tnode.com