New F-Droid repository format for faster and smaller updates
1–10 of 146 posts
Re: New F-Droid repository format for faster and smaller updates
#2I’m trying to understand the JSON merge patch RFC the post refers to.
How does that describe “this key nolonger exists”? Does it perceive ‘key: null’ as being the same as a key not existing?
Edit: oh, it’s in the RFC. I just missed it:
“ This design means that merge patch documents are suitable for describing modifications to JSON documents that primarily use objects for their structure and do not make use of explicit null values. The merge patch format is not appropriate for all JSON syntaxes.”
So it remains simple without any sort of DSL needed to describe changes like “remove this key” by somewhat hijacking ‘null’. Seems like a footgun if you happen to use ‘null’ as a possible value for your schema.
Re: New F-Droid repository format for faster and smaller updates
#3I’m trying to understand the JSON merge patch RFC the post refers to. How does that describe “this key nolonger exists”? Does it perceive ‘key: null’ as being the same as a key not existing? Edit: oh, it’s in the RFC. I just missed it: “ This design means that merge patch documents are suitable for describing modifications to JSON documents that primarily use objects for their structure and do not make use of explici…
>Seems like a footgun if you happen to use ‘null’ as a possible value for your schema.
To be fair, using "null" as a value in your schema without handling the cases where a given key is missing (and therefore the value is null) is also a footgun.
Re: New F-Droid repository format for faster and smaller updates
#4I’m trying to understand the JSON merge patch RFC the post refers to. How does that describe “this key nolonger exists”? Does it perceive ‘key: null’ as being the same as a key not existing? Edit: oh, it’s in the RFC. I just missed it: “ This design means that merge patch documents are suitable for describing modifications to JSON documents that primarily use objects for their structure and do not make use of explici…
>Seems like a footgun if you happen to use ‘null’ as a possible value for your schema. To be fair, using "null" as a value in your schema without handling the cases where a given key is missing (and therefore the value is null) is also a footgun.
I think the main point here is that key present with a null value and key not present are two distinct states and squashing them down into one loses that information.
Re: New F-Droid repository format for faster and smaller updates
#5I’m trying to understand the JSON merge patch RFC the post refers to. How does that describe “this key nolonger exists”? Does it perceive ‘key: null’ as being the same as a key not existing? Edit: oh, it’s in the RFC. I just missed it: “ This design means that merge patch documents are suitable for describing modifications to JSON documents that primarily use objects for their structure and do not make use of explici…
>Seems like a footgun if you happen to use ‘null’ as a possible value for your schema. To be fair, using "null" as a value in your schema without handling the cases where a given key is missing (and therefore the value is null) is also a footgun.
In some cases true. In my case, I don’t allow keys to come and go: they’re always defined. The JSON schemas validate that. But I use null to describe “there is no value for this key yet” (such as dateDeleted). If I were to implement merge patching, maybe by turning on a flag in my given framework, I’d be in for a surprise about what my null values now mean (that the schema catches immediately and never makes it to prod.)
I’m of two minds. I like how simple it is. But they’ve basically ignored a problem because the solution is complex. And so they’re hijacking a data type in a rather perilous way. Maybe they should have specified a magic string value that is treated as “DELETEME” ;)
Re: New F-Droid repository format for faster and smaller updates
#6Thank you!
F-Droid is one of those projects that adds so much peace of mind and usability to my computational life. It is a must-have.
Re: New F-Droid repository format for faster and smaller updates
#7I’m trying to understand the JSON merge patch RFC the post refers to. How does that describe “this key nolonger exists”? Does it perceive ‘key: null’ as being the same as a key not existing? Edit: oh, it’s in the RFC. I just missed it: “ This design means that merge patch documents are suitable for describing modifications to JSON documents that primarily use objects for their structure and do not make use of explici…
>Seems like a footgun if you happen to use ‘null’ as a possible value for your schema. To be fair, using "null" as a value in your schema without handling the cases where a given key is missing (and therefore the value is null) is also a footgun.
> and therefore the value is null
That depends on the interpreter: A good implementation of json distinguishes between defined and undefined keys in the object. Think hasattr(obj, "key") in python, or undefined != obj["key"] in js.
Re: New F-Droid repository format for faster and smaller updates
#8I didn't realize the app was still being worked on. It's been years since the UI update and it's always been amazingly buggy (across 3 different phone). I'm always impressed by how broken it is - especially if you have a slow connection. Downloads will randomly go into a weird frozen state where they can't be stopped. The download status will change when you change tabs/sections. Sometimes download will go past 100% (I managed to get past 200% the other day). If you leave FDroid in the background or lock your phone then it's almost guaranteed to not work
I almost exclusively use FDroid, it's an amazing project. But I've never seen an app with so many issues
Re: New F-Droid repository format for faster and smaller updates
#9I didn't realize the app was still being worked on. It's been years since the UI update and it's always been amazingly buggy (across 3 different phone). I'm always impressed by how broken it is - especially if you have a slow connection. Downloads will randomly go into a weird frozen state where they can't be stopped. The download status will change when you change tabs/sections. Sometimes download will go past 100%…
Agreed. I wonder if it falls into traps that simply didn't exist in the past, and release notes about breaking changes regarding those increasing blurry-but-not-killed modes were ignored.
Re: New F-Droid repository format for faster and smaller updates
#10Earlier quoted context omitted.
>Seems like a footgun if you happen to use ‘null’ as a possible value for your schema. To be fair, using "null" as a value in your schema without handling the cases where a given key is missing (and therefore the value is null) is also a footgun.
> and therefore the value is null That depends on the interpreter: A good implementation of json distinguishes between defined and undefined keys in the object. Think hasattr(obj, "key") in python, or undefined != obj["key"] in js.
Gosh. If “undefined” was part of JSON and it was always 100% semantically identical to “this key doesn’t exist on this object” then I could see myself not hating “undefined”. Unfortunately “undefined” in javascript isn’t even the same as “key doesn’t exist.” It’s just another null type.