Juan Pedro Bolivar Puente <[email protected]> writes: > David Vazquez wrote: >> Is there any reason to we have got the `pdf_fsys_create' procedure? >> It is supposed do: >> >> -- Function: pdf_fsys_t pdf_fsys_create (struct pdf_fsys_impl_s >> IMPLEMENTATION) >> >> Create and return a new filesystem variable that will use a given >> implementation. >> >> which copy the `pdf_fsys_impl_s' structure. >> >> I think we could assume pdf_fsys_t is a pointer to pdf_fsys_impl_s >> (rename pdf_fsys_impl_s to pdf_fsys_s), in order to the library can >> provide PDF_FSYS_DISK, PDF_FSYS_HTTP, etc, to use as pdf_fsys_t >> directly. >> >> If you agree, I will change this. >> > > If I understand your approach well, there is no possibility to associate > state to the fsys variable. In the current implementation there is no > such state, but if we feel the need we could do it by adding it to > struct pdf_fsys_s. Actually, it seems reasonable to have a void* in > pdf_fsys_s that is managed by the fsys impl as instance data. > > JP
It is possible to associate state yet, since it will be a pointer to the pdf_fsys_s structure, which could be allocated at runtime (or not). In fact, we can hold splited pdf_fsys_t and pdf_fsys_impl_t types, but we should provide a pdf_fsys_s structure too in order to we can be initialize them at compiler time. Then, this avoids (though allows) initialize/destroy filesystems with the library. So we can keep definitions functions too. I mean provide a pdf_fsys_s structure internally, I do not mean for library users.
