Re: Gnome-Bounties - Conversations - Was [Re: [Evolution-hackers] Re: [Evolution] proper threading headers]

[Not Zed <notzed ximian com>]

On Fri, 2005-06-17 at 10:02 +0800, Ow Mun Heng wrote:
> On Thu, 2005-06-16 at 16:15 +0200, guenther wrote:
> > On Thu, 2005-06-09 at 14:46 +0800, Ow Mun Heng wrote:
> > > On Wed, 2005-06-08 at 18:26 +0200, guenther wrote:
> > > /me also wishes to know if Evo will only day support or divert somewhat
> > > from the RFC and implement support for Exhange's "Thread-Index" for
> > > threading. Since Evo is being ported to Windows(r) I guess this is a
> > > valid question.
>
> > Well, maybe Evo could use this Micros~1 specific header, just for the
> > convenience of its users. But it should never ever use this header when
> > sending mails, unless it actually gets an RFC.
>
> I agree with this. Then there's another question that begs asking. I'm
> not sure how often RFCs are updated etc, but if innovation/features such
> as this gmail conversations isn't in the RFC, and it's something new,
> and only gmail uses it, it would mean they're not following the RFC/open
> standards and thus unacceptable? How then can innovation occur? 

Umm, this has nothing to do with rfc's, it is an application feature.

The rfc's only say how messages should be replied to, so that clients
*may* be able to do something with the results, but it doesn't say
*anything*, nor should it ever, about how such results should be
presented.  gmail just found a way that works well with web-pages to
display a long conversation, but it is almost certainly just using the
references/in-reply-to headers like we do for threading - i.e. it is
using the rfc standard on replying to messages, it isn't adding anything
new there.

So a flat thread view is a client feature, not an interoperability
thing.  rfc's are for interoperability points.

The microsoft way was just to make up some entirely new header which
probably just makes their mechanism easier to implement.  But, like not
sending out proper references headers, if we dont have all the other
'thread index' values, it is probably completley worthless information
and we can't do anything with it anyway.

Innovation isn't that good when it comes to standards.  Thats why
standards exist and are better when they're stuck to for certain jobs,
and why they shouldn't change constantly.

e.g. wouldn't it really suck if every pipe manufacturer made their own
sized pipes and fittings (like they used to)?  You'd always have to
either get all your pipes and fittings from the same manufacturer, get
custom parts manufactured (if patents allow), or replace the whole lot,
to do any work on any plumbing system.  And what happens when the
manufacturer goes out of business?  But standards mean you can get parts
from anyone and they all just fit together and work (well they do here
in Australia, i've seen mixed results in other places - because the
standards aren't so well defined or adhered to, or there is enough
inertia to keep multiple standards around).

Still, assuming everyone sticks to those standards, and everyone uses
the same thread, the same fittings, so you can get them from any
manufacturer (== lower cost).  But ... you can still get dozens of
differnet types of shiny taps that work in one of several different
ways.  So there's still plenty of room for innovation, outside of the
'standard' plumbing that makes everything work.

Innovating by having a new type of thread connection to plug your taps
into the plumbing is probably not that useful an innovation, unless it
really is much much better than what the 'old stale standard' already
defines.

No 'end user' sees it anyway, they're just more concerned about their
shiny new taps matching their shiny new bathroom tiles or impressing
their neighbours with how flash it looks.

RFC's define the plumbing of the internet, we define the taps and drains
(or sometimes the toilets ;-).  They interact, but they dont overlap.


> I've been asked, if everyone follows open standards, which takes ages to
> finalise, how is innovation gonna survive/surface? 

They just dont understand what standards are for and why they are
needed.  RFC's are created all the time too, it isn't a static system
(certainly not as static as plumbing).