incorporate the pre bed thought
parent
d5631dfa27
commit
df979ff7a1
31
README.md
31
README.md
|
@ -4,23 +4,18 @@ being an ambient activity feed for tilde.town
|
|||
|
||||
## development plan
|
||||
|
||||
TODO: when I wake up, reevaluate the `~/.bustle.spool` file idea to see if I can avoid a bunch of
|
||||
coding / socket programming. also think through if i want any kind of database backing to keep track
|
||||
of stats for the sake of throttling (ie detecting cron/bot writes over time).
|
||||
|
||||
- [ ] skeletal server
|
||||
- [ ] skeletal client
|
||||
- [ ] proof of concept inotify handler
|
||||
- [ ] manually created proof of concept spool files for a few users
|
||||
- [ ] basic `bustle update <something>` (decide on protocol)
|
||||
- [ ] receiving client update
|
||||
- [ ] basic `bustle update <something>`
|
||||
- [ ] seeing the update on the server
|
||||
- [ ] writing audit log
|
||||
- [ ] writing to bustle.log
|
||||
- [ ] basic `bustle` command
|
||||
- [ ] proof of concept inotify implementation
|
||||
- [ ] bbj integration
|
||||
- [ ] user management task
|
||||
- [ ] event aggregation, sampling, and throttling
|
||||
- [ ] ...honestly if you can even get to hear you can worry about what is next then.
|
||||
- [ ] ...honestly if you can even get to here you can worry about what is next then.
|
||||
|
||||
## motivation
|
||||
|
||||
|
@ -81,10 +76,15 @@ events, listening for shouts, and ready to receive API hooks.
|
|||
|
||||
### How should the daemon work?
|
||||
|
||||
- for shouts and bot integration, every user gets a file in /town/bustle/spool/. bustled does a select over every file. a scheduled task adds and removes spool files based on who exists on the system.
|
||||
- for file activity, some kind of inotify watcher.
|
||||
all updates are written to a ~/.bustle.spool file. bots will need a corresponding user account to
|
||||
house this file. alternatively, in the future, bustled can be told about bot spool files in a
|
||||
particular spot; for now there is a one to one between `/home/*/.bustle.spool` files and entities
|
||||
that can tell bustle about stuff.
|
||||
|
||||
#### pre-bed thought
|
||||
these updates are picked up via inotify, which we're already using to aggregate ambient file
|
||||
activity.
|
||||
|
||||
#### (pre-bed thought)
|
||||
|
||||
I'm going through the trouble of setting up inotify. For every user. Instead of doing a socket
|
||||
connection, how about:
|
||||
|
@ -93,9 +93,14 @@ connection, how about:
|
|||
- the `bustle` command just writes to it
|
||||
- i notice those updates by filename and handle them specially
|
||||
|
||||
what are the race conditions here? i think it's ok? if it's inotify based...the bustle client
|
||||
command is just adding to an existing file. the server doesn't care until it's saved and
|
||||
communicated and will only ever read from it. i think this might work D:
|
||||
|
||||
|
||||
### How should user clients work?
|
||||
|
||||
when you run `bustle`, it enters a loop. at some interval, messages print. should a connection be
|
||||
when you run `bustle` with no arguments, it enters a loop. at some interval, messages print. should a connection be
|
||||
maintained with bustled waiting with recv? I don't think so, since the log is not personalized. what
|
||||
if `bustle` is just a fancy `tail -f` on a file, `/town/bustle/bustle.log`? i think that's fine. i
|
||||
want running bustle to be exciting and cute, animating the messages in various ways. someone who
|
||||
|
|
Loading…
Reference in New Issue