/` on Linux and FreeBSD. We follow system-specific conventions and APIs.
- This replaces previous `ApplicationConfig` routine.
- It is consistent with [castle-data:/](https://castle-engine.io/data) which is read-only location with your application data.
2. We added `TCastleMemoryFileSystem` – useful to create a temporary filesystem, living only in memory, registered at given URL.
It is, for now, our implementation of `castle-config:/` on the [web](https://castle-engine.io/web) — so the data is not persistent if you reload the page, but at least it makes sense within a single session. This made our [portable editor](https://castle-engine.io/web-demos/tools/castle-editor-portable/) possible. Of course it is a TODO to actually persist the data using WWW browser mechanisms.
That said, `TCastleMemoryFileSystem` may be useful for your own purposes too, if you want a _temporary virtual filesystem_ in your application.
3. `RegisterUrlProtocol` exposes now a class that allows to configure URL behavior. (So we can extend the functionality offered by custom URLs, aka _virtual file systems_, without adding more and more parameters to `RegisterUrlProtocol`.)
4. Many built-in URLs, and URLs pointing to ZIP (using `TCastleZip`), and URLs pointing to `TCastleMemoryFileSystem`, use above, so their resources can be tested using `UriExists` and searched using `FindFiles`.
5. Queries like `UriExists('castle-data:/my_texture.png')` on the [web](https://castle-engine.io/web) are also useful now, as we use `castle-data:/auto_generated/CastleDataInformation.xml` to test data files existence.
What’s the image shown at this news post? [Chibi Gear Solid](https://sketchfab.com/3d-models/chibi-gear-solid-a4ca0e3864e143af9bf1dffc7fc8029b) by [glenatron on Sketchfab](https://sketchfab.com/glenatron), cool 3D scene rendered using our [Castle Model Viewer](https://castle-engine.io/castle-model-viewer). It has no relation to this news post (except that’s it’s rendered using our engine and you can download it too and turn into a game _right now_!), just something pretty I wanted to show 🙂
---
### Author:  [@michalis](https://forum.castle-engine.io/u/michalis)
#### Post date: [June 28, 2025, 10:19pm UTC](https://forum.castle-engine.io/t/url-improvements-castle-config-protocol-use-uriexists-and-findfiles-on-any-url-including-e-g-zip-tcastlememoryfilesystem/1959/2 "2025-06-28T22:19:04Z")
---
### Author:  [@edj](https://forum.castle-engine.io/u/edj)
#### Post date: [June 29, 2025, 2:56pm UTC](https://forum.castle-engine.io/t/url-improvements-castle-config-protocol-use-uriexists-and-findfiles-on-any-url-including-e-g-zip-tcastlememoryfilesystem/1959/3 "2025-06-29T14:56:29Z")
Would the TCastleMemoryFileSystem work between different programs running on the same machine?
---
### Author:  [@DiggiDoggi](https://forum.castle-engine.io/u/DiggiDoggi)
#### Post date: [June 29, 2025, 7:02pm UTC](https://forum.castle-engine.io/t/url-improvements-castle-config-protocol-use-uriexists-and-findfiles-on-any-url-including-e-g-zip-tcastlememoryfilesystem/1959/4 "2025-06-29T19:02:55Z")
It uses memory stream to hold the data so you would implement memory sharing between your app and the server. However, as the path can be either a real file system on a disk, or an URL, I think you could connect the client to your terrain server simply by HTTP request - you implement kind of “localhost://query” (registered as “my\_terrain:/” protocol) that handles GET to get the chunk of terrain and POST if you need to save the changes made by a player. Good thing about it is that you don’t need to develop own sockets anymore, it’d be just a web page… I may be wrong tho 🙂
---
### Author:  [@edj](https://forum.castle-engine.io/u/edj)
#### Post date: [June 29, 2025, 8:28pm UTC](https://forum.castle-engine.io/t/url-improvements-castle-config-protocol-use-uriexists-and-findfiles-on-any-url-including-e-g-zip-tcastlememoryfilesystem/1959/5 "2025-06-29T20:28:52Z")
I already have socket mechanism for terrain which seems to work pretty well. I was thinking if shared memory file between applications running on same machine could be simpler way for handling things like images and models.
---
### Author:  [@michalis](https://forum.castle-engine.io/u/michalis)
#### Post date: [June 30, 2025, 12:58pm UTC](https://forum.castle-engine.io/t/url-improvements-castle-config-protocol-use-uriexists-and-findfiles-on-any-url-including-e-g-zip-tcastlememoryfilesystem/1959/6 "2025-06-30T12:58:27Z")
Indeed the storage of `TCastleMemoryFileSystem` is just a `TMemoryStream` – so it’s just something that lives in the memory of “this process”, and only this process, it’s not shared. You could try to fork and modify the `TCastleMemoryFileSystem` mechanism to synchronize the underlying `TMemoryStream` in some way, but it’s likely both inefficient and more work than just inventing your own URL 🙂
If you want to use the URLs for synchronizing, you should invent and implement your own URL protocol, it’s starts easy – just use [RegisterUrlProtocol](https://castle-engine.io/apidoc/html/CastleDownload.html#RegisterUrlProtocol-String-TUrlReadEvent-TUrlWriteEvent-TUrlAsynchronousReaderClass-Boolean-) 🙂