[EMAIL PROTECTED] 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
