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? 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 :/ 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. Ben On Tue, Apr 7, 2015 at 8:57 PM, Ali Lown <[email protected]> wrote: > Hi Ben, > > > Sending multiple versions of the email using the MIME implementation > would > > be perfect, I have just a couple of questions... > > 1. I would assume we should send "text/plain" and "text/html", should we > > also send something like "application/wave"? What would > "application/wave" > > look like? is there some data format I could use to build this out? > > There is no precedent for this that I know of. "application/wave" > seems like a sensible type to go with for now. > As for the data format, you have a few options: > i) Just include a full wave snapshot base64'd > ii) Just include a URL to the wave on the hosting server, and include > the base64'd delta of what happened last (might not be human > presentable though...) > iii) Include a URL to the wave, and include the blip which 'changed' > in some format (could be base64'd, could be the html render of it, > etc.) > > > 2. What are we expecting in this email... is it just any new blips that > are > > unread on my wave? When should it be sent if its a noisy wave? (should we > > include the last (parent) blips?) > > Heh. Ties into above. > > This is really the 'digest' question in disguise. Do we expect instant > notification mails, or hourly/daily/weekly digests with everything in? > (Or do we really want both!) > > > 3. Should emails be created for public waves? > > At which stage of 'public'? Once a user contributes to a public wave, > they become an explicit participant, at which point I would expect > them to get emails. If they manually add themselves as an explicit > participant without changing anything, I would also expect emails. > Otherwise no. > > *But* we could include it in a digest of some form. It really depends > on how busy that server is and what exactly the participants want. > (Think of a private server amongst a few friends vs a public server > run by a large company). > > > The postfix solution sounds perfect :) > > 4. I take it the autogenerated email address will just be the same as the > > wave id we use? > > Yes, that is what I would use, and then bodge in an MTA. It may be > nice to offer the email 'domain' part as a configurable option for the > wave server though (not really any more work). > > Ali > -- Regards Ben
