3 ms·

Sadly protocols are made by those who show up and put the effort in. I'll pass a link to this comment on to the list and see if others chime in. The downside

Sadly protocols are made by those who show up and put the effort in. I'll pass a link to this comment on to the list and see if others chime in. The downside of allowing filtered getMailboxes is more protocol complexity, but maybe it's worth it. On to the next topic: Cyrus creates the entire blob. Even when it's streaming a LIST reply it still batches a lot in memory. You'll discover pretty fast if you don't do that, you might wind up holding a lock for a LONG time if you're trying to build consistent replies and the remote end is on a slow network link or just consuming slowly. So we batch all replies right now. If I was building a brand new product I might use an engine which supported MVCC (like Postgres database for example) and hence have flexibility. Having said that - even then you might find that a server talking to slow clients would want to buffer to temp file and free up memory and locks while it streamed the data. With HTTP we get around this by having nginx handle all the mess, so I guess that's what will happen with JMAP too, nginx buffering large bodies to disk.

mike-cardwell 9y ago
> Sadly protocols are made by those who show up and put the effort in. Yes. And like everybody, I have my own priorities, and will not apologise for JMAP not being one of them. Somebody like yourself who is actually invested in making JMAP a success should welcome people pointing out real life use cases where the protocol you're trying to improve upon actually works better than the one you've come up with. I would hope you're spending significant effort trying to get people to look over your spec and point out flaws.
- jsmthrowaway 9y ago
  > Somebody like yourself who is actually invested in making JMAP a success should welcome people pointing out real life use cases where the protocol you're trying to improve upon actually works better I'm pretty sure it was welcomed, and you were invited to contribute, and even after you declined to do so your comment was still acted upon. You're not coming off super well in this thread, by the way: "I have feedback and time to engage a HN subthread, but getting involved with the actual thing I'm criticizing is a burden I choose not to bear, and this is your problem and you should change to accommodate me." (I don't think that's what you intend, but that was what I read.) There's a bunch of snark in this thread I don't comprehend. It seems like a fine exchange? Everybody's friends?
  - mike-cardwell 9y ago
    > I'm pretty sure it was welcomed, and you were invited to contribute. I was invited to join a mailing list and try to convince people that my protocol change was important. There is nothing unreasonable about saying no to this request. > (You're not coming off super well in this thread. "I have feedback and time to engage a HN subthread, but getting involved with the actual thing I'm criticizing is a burden I choose not to bear, and this is your problem and you should change to accommodate me.") "I have useful feedback and I am offering it for free" "Sign up to this list and try to convince people to do work" "No thanks" Wow, I'm such a bastard.
    - deleted 9y ago
      [deleted]
    - sigzero 9y ago
      > Yes. And like everybody, I have my own priorities, and will not apologise for JMAP not being one of them. That could have been said better considering he was taking your comment for possible action. If you don't think that comment is a bit snarky, so be it. I do.
oddlyaromatic 9y ago
>Sadly protocols are made by those who show up This is a very high burden to place on casual feedback from somebody trying to be nice.
- deleted 9y ago
  [deleted]
- brongondwana 9y ago
  I'm not quite sure how to respond to this. The IETF is aware that there's already a high burden on people, that decisions tend to be made mostly by the people who can get to meetings and talk in the rooms where standards are hashed out. Having said that, I'm not sure I agree that it's an unreasonable burden to ask somebody to join a mailing list and defend an opinion if they want to influence a standard which will hopefully be useful for tens of years and implemented by hundreds or thousands of people. Any additional complexity for server and client implementers becomes quite a lot of work multiplied by all those people, and the additional burden of implementing a bigger standard may even be enough to discourage people from using it at all. And it's a fact, the decisions are made by those who show up and put the work in. Wishing it was otherwise doesn't change the reality that we need to make tradeoffs and that the IETF favours rough consensus and working code. Both of which take work. I will forward this discussion to the mailing list, that's about all I can do as chair, I won't proxy all the IETF work over to comments on HN!
  - oddlyaromatic 9y ago
    That makes sense. I think you jumped to quickly to interpreting the original comment as an intent to influence the standard. I read it as just "here is a thought that might be useful/relevant to the people who are making the thing so that they can use it as they see fit when making the standard". No big deal either way!

mike-cardwell 9y ago

> Sadly protocols are made by those who show up and put the effort in. Yes. And like everybody, I have my own priorities, and will not apologise for JMAP not being one of them. Somebody like yourself who is actually invested in making JMAP a success should welcome people pointing out real life use cases where the protocol you're trying to improve upon actually works better than the one you've come up with. I would hope you're spending significant effort trying to get people to look over your spec and point out flaws.

jsmthrowaway 9y ago
> Somebody like yourself who is actually invested in making JMAP a success should welcome people pointing out real life use cases where the protocol you're trying to improve upon actually works better I'm pretty sure it was welcomed, and you were invited to contribute, and even after you declined to do so your comment was still acted upon. You're not coming off super well in this thread, by the way: "I have feedback and time to engage a HN subthread, but getting involved with the actual thing I'm criticizing is a burden I choose not to bear, and this is your problem and you should change to accommodate me." (I don't think that's what you intend, but that was what I read.) There's a bunch of snark in this thread I don't comprehend. It seems like a fine exchange? Everybody's friends?
- mike-cardwell 9y ago
  > I'm pretty sure it was welcomed, and you were invited to contribute. I was invited to join a mailing list and try to convince people that my protocol change was important. There is nothing unreasonable about saying no to this request. > (You're not coming off super well in this thread. "I have feedback and time to engage a HN subthread, but getting involved with the actual thing I'm criticizing is a burden I choose not to bear, and this is your problem and you should change to accommodate me.") "I have useful feedback and I am offering it for free" "Sign up to this list and try to convince people to do work" "No thanks" Wow, I'm such a bastard.
  - deleted 9y ago
    [deleted]
  - sigzero 9y ago
    > Yes. And like everybody, I have my own priorities, and will not apologise for JMAP not being one of them. That could have been said better considering he was taking your comment for possible action. If you don't think that comment is a bit snarky, so be it. I do.

oddlyaromatic 9y ago

>Sadly protocols are made by those who show up This is a very high burden to place on casual feedback from somebody trying to be nice.

deleted 9y ago
[deleted]
brongondwana 9y ago
I'm not quite sure how to respond to this. The IETF is aware that there's already a high burden on people, that decisions tend to be made mostly by the people who can get to meetings and talk in the rooms where standards are hashed out. Having said that, I'm not sure I agree that it's an unreasonable burden to ask somebody to join a mailing list and defend an opinion if they want to influence a standard which will hopefully be useful for tens of years and implemented by hundreds or thousands of people. Any additional complexity for server and client implementers becomes quite a lot of work multiplied by all those people, and the additional burden of implementing a bigger standard may even be enough to discourage people from using it at all. And it's a fact, the decisions are made by those who show up and put the work in. Wishing it was otherwise doesn't change the reality that we need to make tradeoffs and that the IETF favours rough consensus and working code. Both of which take work. I will forward this discussion to the mailing list, that's about all I can do as chair, I won't proxy all the IETF work over to comments on HN!
- oddlyaromatic 9y ago
  That makes sense. I think you jumped to quickly to interpreting the original comment as an intent to influence the standard. I read it as just "here is a thought that might be useful/relevant to the people who are making the thing so that they can use it as they see fit when making the standard". No big deal either way!