svenvc
Handling the memory file system in ZnUrl
This is not an error, but a proposal - or perhaps even just a problem.
I would like to be able to address the memory file system using url/uri syntax. However, it is not clear how to do this. The regular filesystem is solvable because a given computer has only one native filesystem (or so it seems to me).
What I have been experimenting with in some corners of microdown dealing with links to images is to hijack the file url in this manner: file://pseudohost/path. The pseudohost is a key for a dictionary which stores filereferences as values.
I use this in tests, where I set up a memory file system for testing and stores it in the dictionary. file://mem.testing/path then resolves to path in the memory filesystem stored in #mem.testing. I then remove it from the dictionary in the tearDown.
At the moment the dictionary is a class variable in MicFileReference, a class in the core of Microdown.
Now however, I was needing something similar and find myself needing to reinvent it again. The common thing in the two cases is that resources are specified using uri syntax.
Would it be attractive to let ZnUrl have such a class dictionary which could resolve file pseudo hosts? In my usecases it seems like that is where it is needed. I could also just make my own subclass MicUrl which does this.
Hi @kasperosterbye
URLs can be used for lots of things, there are an infinite number of schemes, each interpreting the URL in a possibly different way. Some scheme are standards, like HTTP(S) or FILE. The use of URLs as connection specification is also common. I use that for my P3 Postgres client, my MQTT client and others.
The syntax of a URL (the way it is parsed, split in components and printed) is standard. Giving meaning to the URL, interpreting it, should not be part of the ZnURL class itself, but rather be done by other code, specific for that use case.
For the memory file system, I would suggest using a specific memoryfile:// scheme where you could interpret the host in a special way. Especially managing some global state should never be part of ZnUrl.
What do you think ?
Sven
I tend to agree that such things I ask for should not be inZnUrl. It will be chaos if everybody wanted their hobbyhorse scheme supported in ZnUrl.
Perhaps a way to plug into ZnUrl>>fromString: or an alternative ZnUrl>>schemedFromString: (or some other name). The idea being that one could make a subclass of ZnUrl - e.g. MemoryFileUrl, which will be instantiated rather than the general ZnUrl for a specific scheme name.
I have seen different ways to do "superclass instantiates a subclass", each with different tradeoffs. I prefer simplicity over generality mostly. If MemoryFileUrl is a subclass of ZnUrl and has a class side method schemeName which return #memoryfile, then a call ZnUrl schemedFromString: 'memoryfile://tag/path should instantiate a MemoryFileUrl.
An alternative is to put it in a separate class - say ZnUrlFactory, which will do the parsing and then instantiate based on scheme (creating an instance of ZnUrl as default).
I believe both will work, but some kind of extension mechanism to allow scheme specific instantiation would be useful.
For the time being, I made a subclass of ZnUrl which keeps the dictionary I talked about, and rewrote the asFileReference method to take host into account.