Re: [pdf-devel] Filters deallocation

[Juan Pedro Bolivar Puente]

address@hidden wrote:
> Hi Gerel.
> 
>    I think the Stream module documentation is missing the deallocation 
> operation,
>    the one that deallocs the memory used by the filter itself.
>    ##
>    pdf_status_t pdf_stm_f_somefilter_dealloc (void **state);
>    ###
> 
> As I mentioned in a previous email the pdf_stm_destroy() operation
> will take care about the memory used by 'state' (if any) by calling
> pdf_dealloc.
> 
> 

Is that enough? What if the 'state' contains non-trivial data structures?

Another question, after having received a finish_p in an apply, does the
possibility exist of receiving more data in the future? If that is true
(it could allow more freedom)

I suggest a new interface with 5 operations defined by the filter
(params ommited):

/*
As usual
*/
pdf_filter_init ()

/*
Tells the filter to start a new data processing block. I mean, some
filters might need to add some kind of header to the data, while others
need to add some closing data.

Precondition: the filter has been initialized.
Postcondition: the filter can start processing.
*/
pdf_filter_start ()

/*
Filter actual data.

Precondition: The filter must be started.
*/
pdf_filter_apply ()

/*
Invoqued when there is no more data.

Precondition: The filter must be started.
Postcondition: The filter will not be started. The filter *can be used
again* if start is invoqued again.
*/
pdf_filter_finish ()

/* Clears internal filter data */
pdf_filter_dealloc ()


This kind of protocol is used in many other places where this kind of
filter is needed, such as in audio processing aplications. I also
purpose to decouple encode-decode filters making a separate filter for
the encoder and for the decoder, as implementation usually have no
similarity at all.

What do you think?

JP