Right now, in part due to its alpha state, and in part due to bugs (I can't receive newBlip notifications, etc), emails are only sent when the user writes "bot:send\n". At that very moment, the bot sends a single email.
Regarding synchronization schedule, we could keep a list of "blips not yet synced to email", each of which would have a timeout. Whenever the blip contents is edited, the blip timeout gets reset. Blips that reach the timeout command the bot to sync themselves. Having that basic mechanism, there can be additional rules (for example, all ancestors of a blip have to be synced before the child blip is synced. stuff like that). The timeout period could be configurable, and we can take existing platforms are a reference. Some examples: - GMail's "undo" (the atrophied uncle of Wave's "edit") used to be customizable from 0 to 30 seconds. Recently they increased the limit to 60 seconds. - Some forums and social networks allow to choose "inmediate" (zero seconds) and "daily"/"weekly" (timeout-less cronjobs). - Wiki software often includes a manual checkbox to force/prevent notification messages (so either no wait, or infinite wait). - IM services always operate with zero seconds. - Funnily enough, I can't remember what the options were for Google Wave. I think weekly/daily/hourly? - Etc. Personally, given Wave's nature, I'm inclined to think this should be a per-wave setting (or per wave #tag, or st). There's no single timeout that will satisfy the numerous Wave use cases, so forcing the user to choose one (when the bot is added to the wave) miiight be a good idea. Anyway, this is an endemic issue of the Wave concept: so far nobody has come up with a way to differentiate and adapt Wave's behaviour to the many different communication platforms it can mimic for each specific wave. Traditional communications forms differentiate themselves by forcing the user to choose different clients each time (chat client vs forum URL vs email software vs social network app vs...). Wave eliminates that barrier but provides no way to build the barrier again when it's needed. Automatically detecting "too big" changes shouldn't be too hard, I briefly experimented with it this afternoon: store the plaintext character count in each blip's metadata field (the [mailllist-bot?...] string thingie) when the blip is synced; and don't sync again unless the count has changed X percent and/or Y units. As for federation, I have no idea really. I believe that email synchronization is something requested by a big percentage of wave users, so bundling it with wiab by default, and making it easy and straightfoward to use, can make a lot of sense for Wave's future. Also, you eliminate the dependency from third party servers (I bet most GoogleWave-era bots are now offline...). On Fri, Jun 7, 2013 at 11:59 PM, Ali Lown <a...@lown.me.uk> wrote: > Bruno, > > This looks quite cool. > > The main thing I am thinking is how 'big' an event has to be before > triggering sending an email. (A spelling correction is hardly worth > it) > We also don't want a large sequence of emails being sent for changes > happening within a few seconds of each other (think simultaneous > editing of a large wave), so some sort of time threshold will need to > be considered. > > Regarding federation, where should the bot be (presumably on the > server hosting the wave)? > > Anyway, keep up the work on this. > > Ali > > PS. I suspect infrastructure should be able to put in a special rule > to allow this mail if we can designate some 'official' bot from a > particular server. > > On 7 June 2013 22:48, Bruno Gonzalez (aka stenyak) <sten...@gmail.com> > wrote: > > So I've been working on this for the past days. Still a work-in-progress, > > and will need at least another week of development hours (read: 2-4 weeks > > of actual time) before we can really think about migrating to wave. > > > > The apache mailing list is rejecting the emails from my bot, it thinks > > they're spam. So for the time being, here's a screenshot-based preview: > > http://imgur.com/a/GtGY6 > > > > -- > > Saludos, > > Bruno González > > > > _______________________________________________ > > Jabber: stenyak AT gmail.com > > http://www.stenyak.com > -- Saludos, Bruno González _______________________________________________ Jabber: stenyak AT gmail.com http://www.stenyak.com
