Hi Ben, > I think that you're right to include the wave in full for a first pass.. So > the email would include three parts "text/plain", "text/html" & > "application/wave" > > The above thou may make the email huge in some cases where its a public > wave or there are lots of participants, would it be better for the large > change set just to include all blips since the persons last read blip? and > possibly the last couple of read blips too for context on the wave?
Definitely only include the unread blips, otherwise this could get huge as you say. The only problem with just unread blips, is the lack of context - which would be most noticeable with inline replies. > I'm not sure how we'd test opening the "application/wave" part of the email > thou as we don't have any clients beyond the web one and this can't > currently interact with an email client :/ Indeed. There is no client with support for this currently, but this argument could easily fall into the trap of circular reasoning. No support because no specification, because no implementation, because no major demand, because no support... > So if we make the digest soution both instant and hourlydaily/weekly > configurable, it'd be nice to make this user configurable, do we have any > user setting anywhere? I don't remember seeing any. The only user 'settings's currently are handled through the robots (e.g. the passwordbot). The client already has support for Popups, so creating a settings one which talks over a new RPC channel could be done. Ali
