Re: [pdf-devel] I'm Back at last

[jemarch]

Hi.

   So I'm supposed to be developing the error management module from the base
   layer.  Before starting I'd like to ask some (unrelated) questions.

   1. Can we set a file name convention for sources ?. I thought of something 
like:

      pdf_<layer-name>_<module-name>.[ch]

      Or maybe we could make a directory for each layer and just use
      pdf_<module-name>.[ch], whatever.

I was thinking in a scheme like the following:

Base Layer Modules:

 pdf_<module-name>[_<module-component>].[ch]

Object Layer Modules:

 pdf_o_<module-name>[_<module-component>].[ch]

Document Layer Modules:

 pdf_d_<module-name>[_<module-component>].[ch]

Page Layer Modules:

 pdf_p_<module-name>[_<module-component>].[ch]

What do you think?

   2. Regarding the stream module on the base layer. If I got it right, the 
idea is
      to implement streams on top of some buffer, be it a socket, memory, file,
      etc, (also pdf stream objects are based on them), they are system
      independent, etc. 

Right.

BTW, to avoid confusions with the PDF stream objects it is better to
consistently call the base layer streams as "stms".

      Now, I guess one use would be to read documents suppose over a
      socket using a stream with no filters. Could that be a case ?

Yes.

Note that the processing of a PDF file (maybe linearized) will involve
the use of several stms. For example, the presence of a object stream
will require to use an extra stm with a different filter chain
installed to allow the parser to read the objects contained into it.

The design of stms allow to not read the entire PDF document into
memory before to process it. It also allow for several stms to share
the same underlying storage unit (i.e. a file).

The reader/parser module will get a stm as an argument. The commander
of the parser (the document module in the object layer) will use the
information contained in the xref table in order to incrementally call
the parser to get objects.

   3. For pdf_error I'm considering writing wrappers for those functions 
available
      on lib/error.c and to write new ones for gnupdf as needed. OTOH, I'm 
pretty
      new on the project to know which error types should be added. I guess we
      should analyse each module on each layer and decide from there, don't you 
?

Yes. Each module should be able to define several error conditions on
top of a generic mechanism provided by the error module (the
module-specific error conditions can be implemented in pdf_error.h and
not in pdf_<module>).

I would suggest to design the generic mechanisms first. Maybe
maintaining a global data structure containing a stack of error events
(ala errno).

BTW, you will need a wiki account in order to write down the
architecture/design of the error module. I will create one and send
you the login information.

   BTW, jemarch (and all who contributed), you did a very nice work for the 
gnupdf
   Architecture documents. They seriously lack on most of the projects I've 
been.

Thanks for your words. I think it is important to dedicate time to
design a decent documented architecture.


--
José E. Marchesi  <address@hidden>

GNU Project       http://www.gnu.org
GNU Spain         http://es.gnu.org