-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkp0I4oACgkQchi8veCammcYbgCffy3cT05xgNUoPP0FrTYiFCO0 cwsAn18qaYtaYbIfMvqTwEo5u0MvpGmI =6tIi -----END PGP SIGNATURE-----
