Re: [pdf-devel] File system Definition Functions

[David Vazquez]

Juan Pedro Bolivar Puente <address@hidden> 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.