#dev 2024-08-28
2024-08-28 UTC
aaaa, sp1ff, superkuh, IWSlackGateway1, [schmarty]1, [tantek]1 and [jeremycherfas]1 joined the channel
# 
capjamesg[d] [snarfed] Yeah. I'm not really sure how to best save to disk periodically. Any ideas?
[Joe_Crawford]1, thegreekgeek, [snarfed]1, lockywolf_, wiktor1, CRISPR, GuestZero, aaaa, ancarda, eb, nnrx, srushe, suki, okCiel, capjamesg, roxwize, vikanezrimaya, ttybitnik, AramZS, freecrypto and CatalystND joined the channel
# 
[snarfed] capjames durability is hard to tack on after the initial design. I guess I'd start with, what are your design goals/req'ts? is it a system of record for data? if not, will it be colocated with the primary datastore? what kind of availability, consistency, correctness, etc do you need? etc
Lars-Christian joined the channel
# superkuh Strongly disagree with fragmenting RSS/Atom feeds now by adding "communication" in the style of the HTTP "upgrades" after 1.1. Those upgrades mostly were bad for human persons and devoted entirely to the use case of corporations and institutions. The biggest thing I'd like to see with feeds is large organizations like those not setting default cloudflare up and blocking feed readers from accessing feeds.
# superkuh Technically it's perfect as is, like IRC.
# superkuh The idea of embedding video in feeds and being worried if they won't display is a different angle than I'm used to. For me a feed reader is used to open links in a browser, not to try to render everything there.
# superkuh That just leaves you with a constantly growing whateverlibyouchoseforvideorenderingstuffkit tech debt.
# superkuh Wow. Every paragraph I just disgree more. I'm trying to find something I can agree with here but... yike.
# superkuh KISS, imo.
# superkuh One positive aspect of the article is the link to the IETF web feeds list.
# superkuh That is my point. http/1.1 is great.
# superkuh http/2 and http/3 with their limited a no ability to connect to a remote webserver without that server first getting a short term permission certification from a corporation is bad.
# superkuh "limited" and "no"
# 
[KevinMarks] I thought you'd like that one
# capjamesg[d] [snarfed] How would I design a durable system?
# capjamesg[d] (I know that's a loaded question. I need a map to help me refine it.)
# capjamesg[d] Re: availability / consistency: I thought about building in replication but it's not something I need.
# capjamesg[d] (yet)
# capjamesg[d] I guess I could use an append-only log that saves records as they come in, then load from that to reconstitute the database?
# capjamesg[d] That would allow for the records themselves to be stored in real time, since saving a single record to a file on an add() operation is inexpensive.
sp1ff` joined the channel
# capjamesg[d] But as for the indexes themselves, it isn't as easy. I guess it would be okay to recompute those since that happens on an add() call anyway.
# capjamesg[d] Thank you so much!!!
# capjamesg[d] [snarfed]++
# 
Loqi It looks like we don't have a page for "durable" yet. Would you like to create it? (Or just say "durable is ____", a sentence describing the term)
# Loqi It looks like we don't have a page for "resilient" yet. Would you like to create it? (Or just say "resilient is ____", a sentence describing the term)
# Loqi It looks like we don't have a page for "robust" yet. Would you like to create it? (Or just say "robust is ____", a sentence describing the term)
# 
[tantek] durable is /longevity
# [tantek] resilient is /longevity
hasanhaja joined the channel
# [snarfed] https://en.wikipedia.org/wiki/Durability_(database_systems) is fine, we could just link to that
# [tantek] yes "durable" from a user perspective is more about /longevity
btrem joined the channel
cuibonobo joined the channel
benatkin joined the channel