Eventing: Name CronJobSoure

[n3wscott]

CronJobSource feels misnamed because it is unlike an extension to k8s CronJobs where you can pass an image to, it is a periodic static payload event generator.

It does use cron time as part of the arguments.

It takes a fixed payload now and sends that to a sink on a cron period.

What should this thing be called??

[n3wscott]

I feel like Cron is a right word, and Source could be correct, and the Job part throws me off because you can't really provide a job for this thing to do.

[n3wscott]

CronTemplateSource

It is a Cron of a template sending to a sink.

[n3wscott]

TemplateSource

The cron part is implied by the spec and we could open it up to be a one off?

[n3wscott]

CloudEventsSource

It sends a CloudEvent to a sink.

it is not the same as a http proxy that cloudevents the payload, that would be something like a CloudEventProxy

[n3wscott]

CloudEventsTemplate

It is a template that sends cloudevents to a sink. (the source part is implied by the api group)

[nachocano]

I think Cron and Source should be there. IMO having Source as a suffix is a good practice, even though it might be clear from the apiGroup. Some folks (including myself) usually look at the kind, and if it's self-explanatory, even better...
On a similar note, ApiServer instead of ApiServerSource will be quite confusing..

If Job is the controversial part, then we can remove it and maybe have:

CronSource?

[n3wscott]

IMO having Source as a suffix is a good practice

I just don't like the stutter for most cases.

[grantr]

I agree the Job part is confusing because it's unrelated to k8s Job and CronJob. Thanks for coming up with some creative options @n3wscott. Of all the proposals so far, my favorite is CronSource It seems accurate and unlikely to confuse anyone.

[aslom]

Maybe CloudEventSource if CronSource is still confusing?

[lionelvillard]

Cron = Command Run ON

ScheduleSource ?

[n3wscott]

oh I kinda like ScheduleSource how would you feel if it was more like ScheduledSource

[rhuss]

CloudEventsSource

Does not any source sends cloud events to a sink ? This is too generic IMO.

[rhuss]

Other suggestions:

• SchedulerSource
• TimerSource

Or some names which focus on the constant data that is sent:

• AlarmSource
• PingSource

Tbh, I would love to see two such sources:

• A PingSource for firing events in regular intervals (e.g. with a default schedule of "* * * * *" but overridable). The ping payload would be a constant field (like now)
• ACronJobSource which takes a full pod-spec for creating enough to create a CronJob from an image. This kind of source would reall deserve then the name CronJobSource. The difference to the "naked" combination SinkBinding + K8s CronJob would be that a CronJobSource would create K8s CronJob (and sink binding) in the background and would be fully managed by the operator, making the source completely opaque to any client (and woudl be a perfect fit for a FaaS like use case where you automatically create the source together with a trigger, so creating a per-trigger source).

[antoineco]

So far ScheduledSource is what resonates the best with me. It's to the point and not overly specific ("cron" is a software utility, not an english word) 👌

I don't think it is necessary to include the term "template" in the name, this will be clear from the Source's spec. Likewise, as @rhuss mentioned, all sources emit "events", so I would exclude that term as well.

Just for the sake of adding another suggestion to the mix:

• ScheduledPayloadSource

[lionelvillard]

+1 for ScheduledSource.

[aslom]

ScheduledSource sounds good to me too

[aslom]

Other possibility S7Source (saves 7 letters when compared to writing Scheduled 😱 )

[rhuss]

Sorry to play the German here :), but is it really the Source that gets Scheduled ? Any other source that I know uses the scheme <Noun>Source (ApiServerSource, GitHubSource, KafkaSource). So in this sense, it would be more natural to call it SchedulerSource.

[rhuss]

(also it might be confused with _container scheduling_, but that's probably only a minor issue)

[n3wscott]

(also it might be confused with _container scheduling_, but that's probably only a minor issue)

That is my hangup with SchedulerSource

but @rhuss makes a compelling case for ScheduleSource.

[nachocano]

Sorry to play the German here :), but is it really the Source that gets Scheduled ? Any other source that I know uses the scheme <Noun>Source (ApiServerSource, GitHubSource, KafkaSource). So in this sense, it would be more natural to call it SchedulerSource.

+1 to ScheduleSource over ScheduledSource...

[n3wscott]

EventSendOn aka ESON

taking a page from CRON = Command Run ON

🦆

[n3wscott]

SendOnSource SOS

[rhuss]

ScheduleSource is ok, but whats about a PingSource, which an optional schedule (and by default pinging every minute/second) and data ? I mean, we are not really actively starting something periodically, we just firing constant data.

[rhuss]

HeartbeatSource would another suitable name focussing on the most prominent use case of this source.

[n3wscott]

I do like PingSource, if you make a PingSource and make no change to the spec it does a ping like you say at 1 minute and there are some places to change the default payload and the default time...

I like it.

[n3wscott]

PingSource I would assume also logs the round trip time for each send event. Or maybe that is the main metric it is exposing.

[grantr]

My gut reaction favors PingSource with ScheduleSource a close second. My rationalization is that "Ping" seems like it describes the event more than "Schedule" which describes the configuration of the event. But I would be happy with either. @n3wscott has a point that PingSource might be a better name for something that is measuring a round trip time.

ScheduledSource sounds wrong to me for the reasons @rhuss mentioned. I'd expect that to be doing what k8s CronJob does (start the source on a schedule)