ReFramework split - with and without Orchestrator

Not sure if it should be in Ideas or the new category… please move if needed.

Are there any plans to split the ReFramework into branches for working with Orchestrator and without it?

While I admire the amount of work you’ve put into it, I think it might be trying to do a little too much and it might become confusing.
Splitting it, maybe not yet but in the not too distant future, would allow it to evolve with a clear goal focus:

  • for Orchestrator version to enable as quick start of actual implementation and reliable/repeatable configuration as possible while leveraging Queues etc.
  • for non-Orch version (which by definition would be different scale) to provide “plumming” that eases not having Queues, Assets etc. available.

I don’t really have a horse in that race. Just a thought that I’d like to share :slight_smile:

4 Likes

Personally I agree with you, I had the same feeling when I evaluated it. Right now it’s meant to be usable with both Orchestrator and local mode (excel or other), but in reality it’s more geared toward Orch because that’s how it was used mostly.

If we’d branch it in 2 it would serve it’s purpose more: ensuring best practices for both scenarios and lowering implementation effort.

But officially, we recommend Orchestrator, since that’s where we have the most experience, and we do encourage the community to fork and improve it on git.

It’s an excellent idea but if this is going to happen it will be community driven. Our focus is Orchestrator.

Ok, in that case can you streamline the ReFramework to only use Orchestrator related queueing? It’s confusing to have both.

1 Like

So if there is a use case for splitting this in 2, then how safe is it to assume that there can actually be more than 2 templates? If you were to be able to create your own templates how would they look? I guess this is an open question to everyone reading this thread.

1 Like