# Request for Feedback: Solid Migrator spec and vocab

**URL:** <https://forum.solidproject.org/t/request-for-feedback-solid-migrator-spec-and-vocab/4852>\
**Category:** Solid Specification\
**Created:** [November 10, 2021, 3:00pm UTC](https://forum.solidproject.org/t/request-for-feedback-solid-migrator-spec-and-vocab/4852 "2021-11-10T15:00:49Z")\
**Posts on this page:** 1\
**Showing post:** 3

<div class="post-metadata">

**Author:** ![Potherca](https://dub1.discourse-cdn.com/flex017/user_avatar/forum.solidproject.org/potherca/32/1761_2.png) [@Potherca](https://forum.solidproject.org/u/Potherca)\
**Post date:** [November 25, 2021, 1:51pm UTC](https://forum.solidproject.org/t/request-for-feedback-solid-migrator-spec-and-vocab/4852/3 "2021-11-25T13:51:18Z")

</div>

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](https://github.com/pdsinterop/solid-migrator/blob/HEAD/Solutions/3-meta-pod.md), 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/](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](https://github.com/pdsinterop/solid-link-metadata/issues/2) 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.

Anyway, great feedback thus far, thanks again!

---

_[View the full topic](https://forum.solidproject.org/t/request-for-feedback-solid-migrator-spec-and-vocab/4852)._