Hi,
one thing that I noticed only today is that the
format uses the workspace, store, feature names
as the folder and file names for storage.
Wondering, what happens if we have one or more
chars that are not writable, or if the file system
is simply not ready to accept certain UTF-8 chars?
For the former, I guess we need validation rules
in place in the catalog itself (or replicate
them in the UI and in RESTConfig).
But for the latter, humm...
Alternatively, do we have any good escaping rules?
Something like URLEncoding, but for the FS?
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
Yeah, this is a good point. While certain file systems are capable of encoding type names with extend characters in them, I think we should try to discourage from doing so whenever possible.
One possible solution would be never to use extended characters for directory and file names, running through some encoding/escaping first. This should not be an issue for everything but workspaces, since the actual names are defined in the xml file, and there should be no problem storing the chars there. And for workspaces we could easily just throw the a workspace.xml file in the workspace directory to define the name.
Andrea Aime wrote:
Hi,
one thing that I noticed only today is that the
format uses the workspace, store, feature names
as the folder and file names for storage.
Wondering, what happens if we have one or more
chars that are not writable, or if the file system
is simply not ready to accept certain UTF-8 chars?
For the former, I guess we need validation rules
in place in the catalog itself (or replicate
them in the UI and in RESTConfig).
But for the latter, humm...
Alternatively, do we have any good escaping rules?
Something like URLEncoding, but for the FS?
Cheers
Andrea
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.