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

CRON Functionality #177

Open
djsuperchief opened this issue Jul 23, 2024 · 0 comments
Open

CRON Functionality #177

djsuperchief opened this issue Jul 23, 2024 · 0 comments

Comments

@djsuperchief
Copy link
Owner

djsuperchief commented Jul 23, 2024

A CRON is required as a pre-requisite for things like FROM http.
It needs to be high performing and use standard CRON syntax and not some specialised version of it.

CRON needs to be part of the core library so that it can be the core From trigger.
We need to consider how this will affect onward components and how we need to structure FROM's going forward. This may be a breaking change.

Thoughts

Internal pub/sub might be the way to go on this one as we will need to think about how we trigger a FROM component from the CRON. FROM components are the base hosted service and as such will run in their own scope. The CRON cannot be the root from as this will mean that we will need to break current FROM component structure to allow this to execute.
Choices are:

  1. FROM component gets split from single host component into a host and execution. The advantage of this is that it allows us to have a single CRON FROM and then every component can then be executed as part of the chain. The disadvantage of this is that it changes, fundamentally, how the chain is built.
  2. CRON is a second hosted services and it publishes an event into an internal Pub/Sub which gets picked up by a listening FROM component. The advantage here is that from a user perspective, there is little change except saying the chain happens on a CRON. The disadvantage, again, is that each component will need to listen to the event in case it is specified as a CRON.

One way or another, the structure of the FROM has to change to allow a CRON. CRON does make sense to be part of the Core.

The other advantage of this is that a CRON will allow some non from components to now have a FROM that only gets triggered from a CRON.

Further Thoughts
Actually, we do not need to change the behaviour at all. CRON replaces FROM. The addressing all the same but you specify the cron as part of the construction.
You can have a "NONE" CRON which is a generic "run this load of Processing and TO" or you can have a Cron("componenturi", "cron"). The component has to have something implementing ICronable which is then up to the component how the inner implementation works. The basic gist is that FROM continues to work as is.

CRON is essentially a built in FROM component. Start / Stop all the same and the actual execution is done on...well...cron.

I think it could work and will mean we can do components that haven't got a FROM to have a FROM (SQL, S3 etc).

One thing worth considering is do we implement an overall Kyameru CRON with jobs or just implement per chain?

@github-project-automation github-project-automation bot moved this to ICEBOX in Kyameru Jul 23, 2024
djsuperchief added a commit that referenced this issue Jul 24, 2024
djsuperchief added a commit that referenced this issue Sep 16, 2024
TDD this one
djsuperchief added a commit that referenced this issue Sep 17, 2024
djsuperchief added a commit that referenced this issue Oct 15, 2024
djsuperchief added a commit that referenced this issue Oct 16, 2024
djsuperchief added a commit that referenced this issue Oct 17, 2024
djsuperchief added a commit that referenced this issue Oct 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: ICEBOX
Development

When branches are created from issues, their pull requests are automatically linked.

1 participant