[Proj] Virtual File Access
gdt at ir.bbn.com
Fri Jul 26 11:43:24 EST 2013
Frank Warmerdam <warmerdam at pobox.com> writes:
> Suffice it to say that there are other contexts in which deployments of
> PROJ.4 would have been significantly easier and problem free if I could
> just have the data files delivered directly in the .so file, and no need
> for special installation rules, etc.
I can see that.
> If you look at the TIFFClientOpen() call, it includes mechanisms to pass in
> what is essentially a virtual file access api.
I see - I had not realized that.
> To some extent my introduction of similar capabilities into GDAL, Shapelib,
> and now PROJ.4 mirrors what I saw in libtiff, libpng and libjpeg.
But that's about user data coming from/going to places other than files,
vs. loading issues for things like grid shift.
> I don't recall a concern from anyone else. If you feel this is a serious
> issue you could request I write this up as an RFC and put it to a vote on
> the metacrs project steering committee. I'm a bit surprised at the concern
> since in normal situations the introduction of this file indirection won't
> affect PROJ.4 library users.
No, it's certainly not serious enough for me to try to drag this through
a PSC. My concern is simply an achitectural cleanliness objection, in
that extra mechanisms that arne't necessary are just extra complexity
and sources of potential bugs. If I'm the only one who has a concern,
you should discount my opinion.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 194 bytes
Desc: not available
Url : http://lists.maptools.org/pipermail/proj/attachments/20130726/42bb4466/attachment-0001.pgp
More information about the Proj