As someone who is literally an old-school hacker gone semi-retired, can someone give me the rationale for going all-JSON?
As a serializer/deserializer efficiency goes, wouldn’t Binary Serial Object Notation (BSON) have made more sense?
However, I am duly impressed with how Stalw.Art takes it to the next level with their consolidation of many protocols under one build tool by language and fewest toolset needed (no Autotool, grep, awk, automake, multi-C suppprt, Flex, Bison).
Tooling around json has universal tooling, sanely structured, and understood, basically the opposite of anything with IMAP.
Probably any structured data like json would be fine, it's basically bikeshedding to argue about json when the real driver behind JMAP is the previous state of email's crustiness
And crustiness of legacy SMTP is very prevalent, notably the RFC 822 common mixed-text content (Text/HTML).
Maybe the old foggity in me is yearning for the good ol’ Text-only SMTP days that were spam-free.
Excuse the pessimism here but we are still perpetuating the weakness of SMTP-related backends, notably HTML inclusion into RFC 822, no?
I see increasing prevalence of link tracking of emails by those who commercialized IMAP … and now JMAP. However, I hope to see more private mail servers but that future of privacy remains cloudy.
Isn't link tracking orthogonal to IMAP? If you don't follow the links/load remote images/etc. on the client, then tracking doesn't occur. Unless I'm missing something?
Lots of people use webmail. JMAP was built with that in mind; shipping a BSON decoder isn't meaningfully more efficient than using the JSON encoder the client already has.
As a serializer/deserializer efficiency goes, wouldn’t Binary Serial Object Notation (BSON) have made more sense?
However, I am duly impressed with how Stalw.Art takes it to the next level with their consolidation of many protocols under one build tool by language and fewest toolset needed (no Autotool, grep, awk, automake, multi-C suppprt, Flex, Bison).
A very nice job.