Re: [pdf-devel] Object layer API

[gerel]

 > Date: Tue, 17 Feb 2009 16:32:39 -0500
 > From: Michael Gold <address@hidden>
 > 
 > 
 > >     - What's the point of header_string?
 > >        - The client probably doesn't care about the header -- they just
 > >          want the library to open a valid PDF.
 > >=20
 > > The user may want to open non-pdf file such as a FDF file, that uses
 > > the "%FDF-" header. Also, we may want to introduce new headers such as
 > > "%GNUPDF-".
 > 
 > Why would we introduce a new header?

Who is the client here ?

BTW, don't forget there is an upper 'document' layer which could provide a
wrapper for all this 'low-level' details (e.g if client==PDFviewer)


 > 
 > For the standard headers, the client could check using the
 > pdf_obj_doc_get_header you proposed, but that still seems like a
 > low-level detail they shouldn't have to deal with.
 > 
 > We could have separate functions for opening PDF or FDF, or a function
 > that returns the type (PDF or FDF).
 > 

Here again, client is ambigous to me. Though the procedure you mention, IMHO, is
in the correct level of abstraction.

Moreover the phrase 'low-level' depends on where you're looking it from, and
although a procedure is defined on some API it's not enough reason for the user
to call it.
Look at the base layer, even if there is a text module and it's public to
whoever needs it, that doesn't mean the user is going to use it. The module is
defined there due to the architecture design and nothing else. Likewise here.


 > >     - Maybe it should be possible to pass a callback function that will
 > >       open and return a stream when necessary (since it may be impractical
 > >       to open all streams ahead of time).
 > >        - Or this type of callback could be handled at the stream layer, by
 > >          creating a dummy stream type that executes callbacks to do the
 > >          real work.
 > >=20
 > > Since 'pdf_obj_stream_new' internally creates an intermediate
 > > representation of the stream in disk, @var{stm} is used just to get
 > > the contents. You can get a reading stream using
 > > 'pdf_obj_stream_open_stm'.
 > 
 > I don't really like the idea of the library creating temporary files on
 > its own.  Opening a file in a library can cause security issues, for
 > example:
 >   http://udrepper.livejournal.com/20407.html
 > (Linux 2.6.27 is needed to protect against this, and I'm sure there are
 > operating systems without this feature.)

Interesting security risk, but if we make all memory-based, how much memory will
we need, on average, to edit a document ?
Maybe we could provide this as an optional feature for the poor user with few MB
of RAM.

just my 2 cents,
-gerel