After my initial post in solid/specification - Gitter, I though it might be a good idea to request feedback from a broader audience, hence my post here.
We (PDS Interop effort) are currently developing an RFC/specification that attempts to mitigate linkrot and make moving/migrating between solid pods easier. We’ve documented our problem definition and proposed solutions at github.com/pdsinterop/solid-migrator.
The spec seems to be about setting servers up to be able to redirect specific individual resources, rather than whole pods or large subtrees of pods. I would expect “migration” to be more about the latter. Or I may have misunderstood
Is we do migrate large chunks of stuff, then we may want to not only but also copy so bother places ill be maintained synced versions for security.
This connects to ideas of “soft links” in a pod, which could be client-side only: something where the solidos and file browsers understand “Here imagine a virtual copy of that” a bit like a file mount.
Thank you for the feedback! To address your points:
The spec seems to be about setting servers up to be able to redirect specific individual resources, rather than whole pods or large subtrees of pods.
Well, the specs is aimed at both! The idea is to enable redirection on separate levels, both low- and high-level:
Within a Resource (for specific entries)
Within a Container (for specific resources)
For an entire Container
This last use-case is what lead to something we’ve dubbed a meta pod, which would only contain a single .redirect file in the root. Such a pod would respond to all requests (except for the .redirect itself), by sending a redirect response to another Pod. This is also the original “migration” scenario we envisioned (inspired by https://solid.community/ going down).
If we do migrate large chunks of stuff, then we may want to also copy so both places will be maintained synced versions
As redirects may be temporary, not permanent, it is not required to delete the original file. Adding a meta entry at the source is sufficient. This is included in our original idea, although I think it would be good to add this as a separate use-case to emphasise the difference with other use-cases more clearly. I’ve opened an issue at our repo for this so we don’t forget. Very good point, thanks!
This connects to ideas of “soft links” in a pod, which could be client-side only: something where the SolidOS and file browsers understand “Here imagine a virtual copy of that” a bit like a file mount.
That’s a topic we’ve been discussing as well. Applications will definitely have to have an understanding of “Do not use this resource, use that one in its place”.
We’ve been trying to create the spec (and vocab) with this in mind, so applications can support different use-cases (across different specs) using the same mechanism without needing to create separate implementations to support each one.
I hope this gives some more detailed insight into what we’re trying to achive. If you have any further questions or comment, please let me know.
Would it also make scaling out certain content easier? For performance or capacity reasons?
Maybe write a book and publish chapters in different locations? Cooperation of different editors?
The Solid Migrator App does just that.
It copies files directly from one pod to another, via the browser, without using any kind of storage. It all happens in memory.
At the code level, it has a fetch() which does a read from one pod, followed by a then() which does a write to another pod.