Automatic harvesting requirements for difference feed service

[Michael Allan]

conseo wrote:
> "Whenever a fresh difference", hmm the first time it is viewed is by
> the writer of the communications post, which is searched. It does
> not exist yet, if I understand your concept correctly. We would have
> to use something like the first not-signed in view of the
> difference. But this is borked as well.  Could you clarify? ...

I forgot that V is the first viewer, prior to step 1.

> > ... use case for MESSAGE DISCOVERY:
> > 
> >   1. V posts a new message to the mailing list.  It contains an
> >      embedded URL for a difference between him and W.
> > 
> >   2. Lurker L is reading his mail and sees V's new message.
> > 
> >   3. L follows the URL from his mail client.
> > 
> >      He is taken to the difference bridge.  He looks at the talk
> >      track and scratches his chin.  A new post appears.  It is
> >      auto-selected and a summary appears in the caption at the top
> >      of the window.
> > 
> >      He reads the summary.  It's the same message he was reading
> >      in his mail client 5 seconds ago.

So the first discovery attempt is prior to step 1 and it fails because
V has not yet posted the message.  Either we must (a) prevent that
first attempt or (b) deal with the problems it poses.  I think (b) is
more robust.  One solution might be to ensure that discovery attempts
are cheap and failures recoverable, because often the next attempt
(step 3) will succeed.

On top of (b), we could later optimize it with a touch of (a): ignore
all views by the most recent editor of the pair (V,W) when the edit
occured within the last hour.  Or something like that.  (But just make
an OPT note of this in the code and save the impl for production.)

Will this work?

> ... I have to think about it as well. I feel a little bit sick
> atm. which is just right for exams :-D, so don't worry if it takes
> some time for me to reply, I will do so.

Get well, C.  Don't worry about this, we can come back to it later.

Mike


conseo wrote:
> On Monday, January 30, 2012 02:33:03 PM Michael Allan wrote:
> > Hi Conseo,
> > 
> > This might be simpler than I expected, because I think we can drop the
> > complexity of the referrer header for archive discovery.  The use
> > cases below center on this mockup of the theatre toolbar and
> > difference bridge: (see callout notes 1 and 2, here)
> > http://zelea.com/project/votorola/a/xf/_/TheatreToolbar/diff-1.xht
> > 
> > Here's the use case for ARCHIVE DISCOVERY:
> > 
> >   1. User U opens discussions on a new issue.  She and her voters
> >      start posting messages with embedded difference URLs to a mailing
> >      list.
> > 
> >   2. V notices that the messages are not showing up on the talk track
> >      of the difference bridge.  He says so.
> > 
> >   3. U says, "That's because I forgot to add the URL of this list's
> >      web archive to my position page."
> > 
> >      So she adds it.
> > 
> > Here's the use case for MESSAGE DISCOVERY:
> > 
> >   1. V posts a new message to the mailing list.  It contains an
> >      embedded URL for a difference between him and W.
> > 
> >   2. Lurker L is reading his mail and sees V's new message.
> > 
> >   3. L follows the URL from his mail client.
> > 
> >      He is taken to the difference bridge.  He looks at the talk track
> >      and scratches his chin.  A new post appears.  It is auto-selected
> >      and a summary appears in the caption at the top of the window.
> > 
> >      He reads the summary.  It's the same message he was reading in
> >      his mail client 5 seconds ago.
> > 
> > So basically the harvester wakes up whenever a fresh difference is
> > viewed in the bridge.  It goes looking for the post on the web.  It
> > looks in the archives listed in the position pages of the common
> > candidate (U in this case), if any, and the individual users (V, W)
> > until it finds a match.  Then it feeds the post to clients like the
> > talk track.