On 9/29/2009 1:00 AM, Jon A. Cruz wrote:
Hi,
Just wanted to point out that technically URI classes are not usable for our assets.
For example, it is tempting to use an URI to resolve an asset to the base document path. The problem is that a URI according to the RFC's is not usable for file paths. Glib and friends properly implement URI, therefore we can't use them for files.
In the future we can probably use IRI's or our own classes for references and assets, etc. However URI's are not usable.
I'm pointing this out since we are just about to release, but I tracked down a critical bug to being caused by this. In the near term we should search through the codebase for improper uses of URI classes. The tricky thing is that they will appear to function since common path names are "safe." However as soon as unexpected characters come in (like ampersands), all bets are off.
To summarize:
If we are linking something that is represented by a file (images, color profiles, etc.) can't be processed with a URI class or URI functions. It will work for simple cases, but not all.
Jon,
(for those uninterested in URI's, please ignore :-)
I suspect there is a problem either with the URI impl or how it is being used.
But I'm kinda pro URIs. Yes, the URI API as stated in the W3C doc does not have a getNativePath() method as far as I know. However, Java's runtime, XML2, and other libs -do- include such a call, and it is quite useful. I think it has become a defacto requirement.
In conjunction with resolve() and normalize(), you should be able to handle paths in a -predictable- manner. Maybe not what you expect, but always the same.
As far as IRI's go, in the specs themselves IRI's are described as URI classes which have been hacked to be able to handle Unicode and international information in the full resource paths. We could take either of the two URI impl's in Inkscape and hack them to work nicely in just a few days' work. I just call them all URI's whether they can handle IRI stuff or not.
The case that you mention, an asset pointing back to the owner doc. Is that feasible, or even promised anywhere? I can easily imagine that resolving owner doc->resource can only be guaranteed 1-way. Especially considering symlinks.
Once again, the "sandbox" comes up. It would be a wonderful thing if we had docs operate in a JAR-like sandbox. If you import an image, it gets copied into the sandbox with the SVG doc (unless you request otherwise). HTML editors work this way. The links within the sandbox are simple and predictable.
And when you JAR the directory into an archive, the META-INF directory and manifest are already ready to go.
This is something we needed for collaboration, too.
bob