Renaming Tardigrade to Storj

[calebcase]

Storj rebranded the product from Tardigrade to Storj DCS. Some users are already asking for it to be renamed in the config ([Storj DCS] uplink: upload done: already committed and "too many open files" · Issue #5310 · rclone/rclone · GitHub). I'm looking for ideas on the best way to rename it while still supporting the old config targets for some time.

Ideally we'd be able to:

• have a tardigrade and storj config section
• automatically migrate configs from tardigrade to storj (assuming users want that)
• only have one set of code to manage the config section
• clearly mark the tardigrade section deprecated some how (and eventually be able to remove it)

What do we think is the best path forward?

[ncw (Nick Craig-Wood)]

I think first step would be to rename the backend from tardigrade to storj.

I can think of several things we could do...

1. Implement a backend which renames all tardigrade type config items to storj then passed the call off to the storj backend

2. Implement an alias backend which uses the storj backend but still reads tardigrade config.

3. Add a new feature to the backend config so that they could respond to more than one type. That probably isn't too hard...

Option 1) would be seamless for the user but isn't both forward and backwards compatible (if you revert back to an older rclone the config will be broken). It definitely migrates the user to the storj backend in a way that 2) doesn't. 3) would be useful if we have to do this in the future.

Note that we don't have the concept of a deprecated backend so if we want to use option 1) or 2) that would need to be added.

Option 3) might be the least work...

In the long run I'd want to delete the stub tardigrade backend.

What do you think?

[calebcase]

Option 3 sounds the best to me. It doesn't immediately lead to to code we'd have to later delete. And it avoids the automatic migration which sounds like it could create unexpected issues if the user uses an older version of rclone with the same config.

Is this a good outline of the work for option 3):

• Add Aliases []string to RegInfo
• Add Aliases() []string to the Features struct with corresponding Aliaser interface (or maybe the Info interface instead?)
• Extend Register(info *RegInfo) to use Aliaser to register the same info once per alias

[ncw (Nick Craig-Wood)]

@calebcase

Option 3 sounds the best to me. It doesn't immediately lead to to code we'd have to later delete. And it avoids the automatic migration which sounds like it could create unexpected issues if the user uses an older version of rclone with the same config.

Great

@calebcase

Add Aliases []string to RegInfo

@calebcase

Add Aliases() []string to the Features struct with corresponding Aliaser interface (or maybe the Info interface instead?)

Adding it to Features will mean all backends have to implement it so I think we probably don't want to do that, same with the Info interface, so I don't think we need this step.

@calebcase

Extend Register(info *RegInfo) to use Aliaser to register the same info once per alias

The registry is a really dumb slice of backends at the moment, so actually searching the aliases in fs.Find() should be enough. The Aliases should be available in the RegInfo in Find.

I think those two things should be enough to make aliases for a backend work. I'm not 100% sure what (if else) might need changing so I'd do that first and see what happens!