![]() ![]() OS configurations can change substantially, as well as my preferred ways of working). I used to try and automate a lot of this with bash scripts, but realised over time that things go out of date quite quickly (e.g. This post is my attempt to capture and document my process for getting a new dev environment set-up. It's something I'm really annoyed Fantastical doesn't do.I’m an engineer with a new laptop, which requires setting up with various development tools and configuration. This is a lot of work, and especially a lot of careful consideration of design from a security and privacy perspective, for what is admittedly a fairly minor bit of UX polish, but on the other hand, dismissing an event on one computer and having it automatically dismiss everywhere feels really nice. This requires maintaining long-lived connections, including dealing with what happens when a connection terminates, when to re-establish communication, etc. MeetingBar could also just advertise that it's running, and then establish and maintain communication with all other MeetingBar instances (and verifying, in a privacy-conscious manner, what EKStores they have in common). ics for the event, but unfortunately EKEvent does not expose that level of access. ![]() I wish MeetingBar could just stick a custom X-MeetingBar-Dismissed key into the. Granted, including any kind of change count or event identifier in the TXT record allows observers to determine that the user has dismissed events, but I think that's probably okay. Heck, the TXT record should probably include a small salt that is included in any hash, such that two machines running MeetingBar with the same accounts use different identifiers in the TXT record, but two instances with the same EKStore can determine that they're the same (by re-hashing their local store identifier+type with the advertised salt and comparing it to the advertised identifier). Anyone who doesn't already have access to the EKStore should not be able to figure out anything about its contents, beyond the fact that MeetingBar is running on a machine and is configured for one or more stores. ![]() Or the key could even identify the last-dismissed event, though I worry about cases where there's multiple overlapping events and so the last-dismissed event may not sufficiently determine if anything's still visible. Maybe you can figure out some reliable way to identify what's been dismissed in the TXT record value so they don't actually have to talk directly to each other, or maybe it could just have a "generation count" that's incremented any time an event from that EKSource is dismissed and MeetingBar can watch for that and ping the instance for details any time it changes. They could register Bonjour services in order to find each other, perhaps using the TXT record to identify the EKSource accounts the user has enabled calendars for (assuming the source identifier is stable across machines if so, use that, or probably hash that + source type just to be sure it's unique and not leaking info). MeetingBar instances on different machines should communicate with each other somehow. When I handle a notification on one of them, it would be nice if the other stopped displaying it. I have multiple computers that run MeetingBar. Is your feature request related to a problem? Please describe. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |