<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">Joshua Cranmer 🐧 wrote on 24.04.2017
      02:30:<br>
    </div>
    <blockquote
      cite="mid:5cb0d3b0-a441-b40d-e097-c9ee4453fe79@gmail.com"
      type="cite">
      <meta http-equiv="Context-Type" content="text/html; charset=utf-8">
      I worry that the options here are "typescript" or "no static
      typing, ever"</blockquote>
    <br>
    Obviously, that's not our only choices. As I already mentioned,
    there is "closure compiler", somebody on maildev suggested that.<br>
    <a class="moz-txt-link-freetext" href="https://github.com/google/closure-compiler">https://github.com/google/closure-compiler</a><br>
    <a class="moz-txt-link-freetext" href="https://developers.google.com/closure/compiler/">https://developers.google.com/closure/compiler/</a><br>
    There are others, e.g. Flow. I haven't looked into it at all, and
    I'd like to have some opinions from people that have worked with
    several systems and can tell us advantages and disadvantages.<br>
    <br>
    <blockquote
      cite="mid:5cb0d3b0-a441-b40d-e097-c9ee4453fe79@gmail.com"
      type="cite">and I think I would personally lean towards the
      former. Compilation steps aren't all that annoying.<br>
      <br>
      <blockquote type="cite"
        cite="mid:2c3900dc-838b-3f0b-3a16-2ef76ae482e9@beonex.com">
        <blockquote
          cite="mid:242e6c07-4cff-f9b3-8664-ceebbae9becc@gmail.com"
          type="cite"> think that establishing tests against a few open
          source server implementations with common data setups in
          Docker containers is the best way to test these components<br>
        </blockquote>
        <br>
        Yup, that's a nice idea. But nothing I'd want to run on my
        machines. I'd want to trigger a "try" build and test server for
        that. Or just land and see whether it passes (see above).<br>
      </blockquote>
      <br>
      The ability to run tests on your local machine is something that I
      consider, as a developer, non-negotiable.</blockquote>
    <br>
    Yes, agreed. I didn't mean to say you cannot. I just said I would
    not want to be forced to do that, but I'd personally prefer a
    service, and we should have such a service for such tests that are
    either long-running or complex to set up. Of course you should be
    able to run such Docker tests on your machine.<br>
    <br>
    <blockquote
      cite="mid:5cb0d3b0-a441-b40d-e097-c9ee4453fe79@gmail.com"
      type="cite">If you've been reading today's IRC backlog, you'll see
      some painful testing happening where the developer in question
      doesn't have access to the thing being tested--and when you have
      40-minute wait-for-results-oops-I-fat-fingered-a-variable-name
      cycles</blockquote>
    <br>
    I've been in the situation myself where my change worked on my
    machine, but failed on CI. Of course these were badly written tests
    (of somebody else). But to debug them, I need to be able to run them
    on my own machine. That's a matter of course, yes. It's a necessity.<br>
    <br>
    <blockquote
      cite="mid:5cb0d3b0-a441-b40d-e097-c9ee4453fe79@gmail.com"
      type="cite"> <br>
      <blockquote type="cite"
        cite="mid:2c3900dc-838b-3f0b-3a16-2ef76ae482e9@beonex.com"> <br>
        * There might not be one single solution for all DB needs in
        TB:NG. It may differ from case to case, so we should evaluate it
        with specific cases where we need DBs and why and what the
        requirements are. You probably have some cases in mind, so why
        don't you just dump your brain somewhere?<br>
      </blockquote>
      <br>
      I have an old start at <a moz-do-not-send="true"
        class="moz-txt-link-rfc2396E"
        href="https://old.etherpad-mozilla.org/tb-new-db-api"><https://old.etherpad-mozilla.org/tb-new-db-api></a>,
      although that was mostly focused on a better way of representing
      the current API in a more asynchronous manner. I've definitely
      advocated in the past for even stronger changes (most notably,
      per-account databases rather than per-folder databases, which I
      think opens us up to better optimizations in cases like deleting
      messages), but that's hard to retrofit in the current API
      assumptions (again, assuming that loading a database gets you
      O(instant) access to any message really cripples what you can do
      in the DB design space).<br>
    </blockquote>
    <br>
    Can you please document your ideas somewhere on the wiki and post
    the link here? I would have gone for per-folder DBs, so I'm
    intrigued by your comment and your rationale. Also your other
    thoughts about DB implementations, where DBs are necessary, and how
    the APIs to the DB and the component should look like as a
    consequence.<br>
    <br>
    <blockquote
      cite="mid:5cb0d3b0-a441-b40d-e097-c9ee4453fe79@gmail.com"
      type="cite"> <br>
      <blockquote type="cite"
        cite="mid:2c3900dc-838b-3f0b-3a16-2ef76ae482e9@beonex.com">This
        is more detail about APIs and implementation that we should
        discuss on this thread, or even at this time.</blockquote>
    </blockquote>
    <br>
    (Funny, I made a 1-character typo here that completely inverts the
    meaning of the sentence. I meant to say: "more detail ... *than* we
    should discuss on this thread".)<br>
    <br>
    <blockquote
      cite="mid:5cb0d3b0-a441-b40d-e097-c9ee4453fe79@gmail.com"
      type="cite">[API to open a folder, based on DB]<br>
      <br>
      This means that the API design needs to start from the assumption
      that "a current list of all messages in the folder" is not
      something that should be presumed to exist as an in-memory
      representation which means filtering even a conceptual list has to
      let the filter be expressed in some manner that lets the query be
      passed down to a DB layer (i.e., not a generic JS function
      parameter). As you say in other messages, the key to performance
      is not doing things that don't need to be done, and getting a list
      of 1M messages so you can show 20 of them on the screen is an
      excellent example of failing that criterion.</blockquote>
    <br>
    That's one way to look at it, but there are other criteria. I can
    accept a small delay when opening a folder, but I cannot accept any
    delay whatsoever during scrolling. My tolerance for scrolling delays
    is what I eyes won't notice anymore, somewhere in the area of 20ms.
    Essentially, as soon as I can *see* a delay when scrolling, it's
    tripping me off, because it breaks the physical metaphor and visual
    expectation we have from reality. Even if it's fast enough 95% of
    the time, but there's a slight delay every 2000th message, it would
    feel like jitter, and would feel like I'm stumbling. It's the same
    thing as with virtual reality: It must be smooth *always*, otherwise
    you get dizzy. For scrolling, it's as disconcerting as with VR, but
    a little bit of the same, for the same reasons. I don't mean
    Apple-style "smooth scrolling", but about avoiding visible delays.<br>
    <br>
    Loads from the drive or network are non-predictable. The drive may
    be busy, or the DB implementation needs longer to find certain
    parts, and some lookups take longer than the 20ms. And then you get
    jitter in the middle of scrolling. For me, that's worse than a delay
    when opening the folder. You're essentially asking for
    "delay-loading lists". I've seen such implementations in some apps,
    and they are deeply disconcerting for me, and they feel slow to me.<br>
    <br>
    I think 1 million emails in a folder are an edge case. We should not
    redesign everything for edge cases, as that will have costs in
    design and implementation time, and might cause other disadvantages.<br>
    <br>
    That said, you're mentioning interesting ideas. I'd be mostly
    interested in supporting them with virtual folders and searches.<br>
    <br>
    I'll give it some thought.<br>
    <br>
    Ben<br>
  </body>
</html>