[x3d-public] url MFString handling

Andreas Plesch andreasplesch at gmail.com
Wed Apr 20 12:13:13 PDT 2022


Thanks Doug. I suspect that moving from localhost to a public server
may be the common use case.

Cross-origin security policies on http servers and www browsers often
restrict access to resources. For portability, relative urls and
moving resources along with the scene files would cause least
friction. But one could imagine a more open resource server used for
back-up purposes (until it may become abused).

-Andreas

> Date: Wed, 20 Apr 2022 06:14:56 -0600
> From: GPU Group <gpugroup at gmail.com>

> sadly freewrl goes down the list untill file found then stops,
> regardless if the contents are the right type or parse.
> DEF II Inline
> {
>    # will it get to cone.wrl? stops at (found) gif, displays black screen.
>   url [ "../helpers/back.gif" "../cone.wrl" "../empty.wrl"
> "../no_exist.wrl"]
> }
> gets to cone.wrl:
>  url [ "../no_exist.wrl"  "../cone.wrl" "../empty.wrl" ]
> stops at empty.wrl:
> url [ "../empty.wrl"   "../cone.wrl" ]
> empty.wrl:
> #VRML V2.0 utf8
> So it seems to be designed for when resources have moved relative to scene
> file, for example
> url["red.png" "helpers/red.png" "http://hostsite.com/scenery/helpers/red.png
> "]
> would save you from reworking your urls when you move from one site
> -localhost- to a public server during scene development.



More information about the x3d-public mailing list