Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add auto_sync method to plugin #22

Open
phlax opened this issue Oct 22, 2015 · 3 comments
Open

Add auto_sync method to plugin #22

phlax opened this issue Oct 22, 2015 · 3 comments
Milestone

Comments

@phlax
Copy link
Member

phlax commented Oct 22, 2015

Im figuring this is what the scheduler could call.

The default behaviour would be:

  • add_translations
  • fetch_translations
  • merge_translations
  • rm_translations
  • sync_translations

Im figuring all but the last step should be configurable - perhaps a syntax like

[auto]
tasks = add
            fetch 
            merge
            rm

or

[auto]
tasks = fetch_force 
            merge
            rm

etc

@dwaynebailey
Copy link
Member

Wouldn't fetch happen first?

So some thoughts from my side:

  • The list approach looks good for now. The proof in the pudding is when we need an alternate
  • Do we allow what steps should happen if there is a failure?
  • Do we want to indicate that we do next step if the previous one was succeesful
  • Alternate could be task.1=, task.2= which could allow failure.2= success.2= - but that might make things complicated.

@phlax
Copy link
Member Author

phlax commented Oct 22, 2015

Wouldn't fetch happen first?

without the force option it wouldnt matter - but with the force option order is important - also relative to the the merge/rm steps.

The list approach looks good for now. The proof in the pudding is when we need an alternate

Yep - we need to give some thought about the best syntax for passing an argument - ie force etc.

I can write up some recipes for this, to explain diff strategies.

Do we want to indicate that we do next step if the previous one was succeesful

My feeling is that (if its easy/possible) we should try and do things atomically - ie all steps fail if any steps fail in auto_sync.

We could have a potentially configurable retry setting.

Alternate could be task.1=, task.2= which could allow failure.2= success.2= - but that might make things complicated.

My head hurts 8/

@phlax phlax added this to the 0.1 release milestone Oct 22, 2015
@dwaynebailey
Copy link
Member

Yep - we need to give some thought about the best syntax for passing an
argument.

I think fetch --force - just like on the command line is most logical

Do we want to indicate that we do next step if the previous one was
succeesful

My feeling is that (if its easy/possible) we should try and do things
atomically - ie all steps fail if any steps fail in auto_sync.

Yes I think I agree. All works or we fail globally. I guess it does
depend on the nature of the failure.

Alternate could be task.1=, task.2= which could allow failure.2=
success.2= - but that might make things complicated.

My head hurts 8/

Agree. Probably less of an issue if we weren't using INI.

Dwayne

Translate
+27 12 460 1095 (work)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants