[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [pdf-devel] Filters deallocation
From: |
Juan Pedro Bolivar Puente |
Subject: |
Re: [pdf-devel] Filters deallocation |
Date: |
Wed, 24 Sep 2008 16:20:05 +0200 |
User-agent: |
Mozilla-Thunderbird 2.0.0.16 (X11/20080724) |
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