sean9999 / rebouncer Goto Github PK

lots of em. go for max coverage

a CI/CD process should be in place to create binaries for all relevant platforms

There is no need to wrap our original events into NiceEvents just to add fields that aren't really necessary.

Let's instead have two generic types: dirty event and nice event.

or Naughty and Nice.

this will obviate the need for user-defined functions to traffic in types that need not know anything about.

a plugin architecture would be smart. Inotify would then be a plug-in. I could try to think of other plug-ins for other use-cases

the platform-independant events are too lossy. we need more detail. go all in on inotify

to make it more generic and composable across languages and systems, let's add gRPC.

Is so, we should think about conforming to the CloudEvent spec

docs: improve

we need far better documentation, plus examples, plus the removal of exported members no longer needed

it's not great to have to great a channel beforehand. There should be a function for that.

Ideally Rebouncer can be a generic way to collect, filter, and re-emit events. Not tied to filesystem and/or inotify

there is a deadlock arising from bad design.

IncomingEvents should not be buffered. Rather, it should accept one event at a time, and process it fully before accepting another.

We also need a LifeCycleState property, or a mutex, or another channel to handle the hand-off between Reducer and Quantizer

we need to handle situations like the root directory being moved and other ways to cancel the incoming event stream, and to cascade that cancellation along the path.

other lifecycle hooks may be important. For example, special events like NiceEvent{Topic: "rebouncer/lifecycle/purge"} could trigger an Emit() or delete the batch without triggering a Emit().

we probably want the context package for this. It seems to make sense to me that an Event should have access to the context of it's parent.

fields such as bootID are not required now, let's remove everything non-essential

merge flat-architecture to develop, and prepare to merge develop to main

by using a ./cmd structure

A Dockerfile and related docs should be set up. Docker can be used to:

• run tests
• make builds targeting different environments
• run vuln checks
• proof of concept for a live-reloaded that can work in docker world by issuing ad-hoc docker exec or docker cp commands in response to rebouncer events. it possibly could even be turned into to Docker Desktop extension

I thought of using the CloudEvent standard, but it's too big and complex. Instead, let's use this format: https://github.com/mustafaturan/bus#processing-events

type Event struct {
    ID         string      // identifier
    TxID       string      // transaction identifier
    Topic      string      // topic name
    Source     string      // source of the event
    OccurredAt time.Time   // creation time in nanoseconds
    Data       interface{} // actual event data
}

The TxID can be the cookie id.

create a default Batcher function that simply creates buckets based on time (ex: 1 second).

• call it Quantize or quantize
• create an interface called Batcher that Quantize can implement
• set the state for passing in funcs (like Batcher) during config phase