Plugins / AutoUpdate Support

[pete...@gmail.com]

Hi there,
Can an autoupdate mechanism be added to the spec so installed plugin
checks back to see if there's a more current version?
This is in reference to http://lists.opensearch.org/pipermail/opensearch-discuss/2007-March/000052.html
Thanks a lot,
Pete

[DeWitt Clinton]

+1  to adding UpdateUrl and UpdateInterval to the core spec and namespace.

-DeWitt

[Mike Connor]

heck, I have draft spec on this since Firefox needs this, which I
think dewitt has seen.

I'll link it when I'm not on a bus..

Mike

[Mike Connor]

I, uh, wasn't on a bus for four days. Oops.

https://wiki.mozilla.org/User:Mconnor/SearchUpdates

Needs to catch up to some of the other 1.1 stuff, like the changes to
url types. we might also just want <UpdateUrl> instead, as DeWitt
commented.

Other than that, thoughts?

-- Mike

[DeWitt Clinton]

Oh, that's interesting.  Combining that with Brandon's Url 'rel' spec and the existing OpenSearch description document mimetype we get:

  <Url rel="autoupdate"

       type="application/opensearchdescription+xml"
       template="https://www.example.com/osd.xml"/>

The only missing bit would be the UpdateInterval.  Which should really be solved with standard HTTP cache headers anyway, so perhaps we don't even need it...

-DeWitt

[DeWitt Clinton]

Wait, nevermind inventing a new rel value.  Just reuse "search":

 <Url rel="search"

      type="application/opensearchdescription+xml"

      template="https://www.example.com/osd.xml"/>

-DeWitt

[Mike Connor]

On Mon, Oct 13, 2008 at 11:21 PM, DeWitt Clinton <dew...@unto.net> wrote:
> The only missing bit would be the UpdateInterval. Which should really be
> solved with standard HTTP cache headers anyway, so perhaps we don't even
> need it...

We needed it in the past for Sherlock plugins so we could specify the
value for app shipped plugins. Not sure if there's a better way to
specify that in flat files on disk.

-- Mike

[DeWitt Clinton]

Couldn't the browser ping the server (at the URL provided) at startup the first time, then check back every now and again after the cache header value has timed out?

-DeWitt

[Mike Connor]

If you mean on first use, yeah, we could do that. I suppose with the
spec requirement to only check when being used we don't need an
initial interval, just check for updates if you haven't, and then use
the server response to set the next threshold before you'll check
again.

As a note, the requirement to check only when in use is designed to
minimize privacy concerns. If you check while searching anyway
there's not much the site can learn that you didn't already tell them
about when and how you're using the UA in question. It also
minimizes/eliminates connections to sites that you are not actually
connected to, which I know many users have taken issue with in the
past (f.e. "why am I connecting to example.com while idle?").

-- Mike

[DeWitt Clinton]

Fair enough.  Then if not proactively on startup for all pre-shipped plugins, then just the ones that the user has selected or used at least once.

-DeWitt

[BrandonLive]

Not all clients are browsers :) Think of SharePoint / MS Search
Server.

Then again, I think most clients would be capable of determining a
suitable update interval. It doesn't really seem necessary for a
server to specify that (and if it did it could just use the HTTP cache
header as you suggested).

Also, +1 on using rel="search" for this!

> > -- Mike- Hide quoted text -
>
> - Show quoted text -

[Gavin Sharp]

On Mon, Oct 13, 2008 at 11:22 PM, DeWitt Clinton <dew...@unto.net> wrote:
> Wait, nevermind inventing a new rel value. Just reuse "search":
>
> <Url rel="search"
> type="application/opensearchdescription+xml"
> template="https://www.example.com/osd.xml"/>

This seems somewhat confusing to me - it's not obvious at all that
this has anything to do with updates to the description file itself,
based solely on the markup. Assuming by "reuse search" you're
referring to the "rel" value in <link rel="search">, I'm not sure that
the reuse is very valuable - they're used in totally different
contexts, and the connection isn't obvious (at least it wasn't to me).
I think rel="update" would probably be better.

Gavin

[DeWitt Clinton]

Fair enough.  And rel="self" works as well, given that's how Atom does it.

So we have proposals now for:

  rel="update"

  rel="autoupdate"

  rel="search"

  rel="self"

Other proposals?  Vote?

-DeWitt

[Mike Connor]

self is ok, but less obvious. Update has the least ambiguity.

If I proposed autoupdate, I'll suggest update is better, since it's
not always automatic.

-mike.

[DeWitt Clinton]

Unfortunately rel="update" is entirely new.

I agree now that rel="search" is bad.  While it points to a description document, that endpoint doesn't describe a way to search the doc itself, so it is inconsistent with the other places we use it.

Thus I'm leaning toward rel="self" just like Atom.  This has the added benefit of being a mechanism for declaring the canonical URL from within the document itself, just in case there are multiple ways to retrieve it.

-DeWitt

[Mike Connor]

The canonical URL argument tips it for me, let's just make it "self" then.

-- Mike

[Gavin Sharp]

I don't understand why it being entirely new is a problem, given that
we're defining the language. "rel=update" is about as intuitive as we
can get without being overly verbose. rel="self" doesn't really mean
anything to me.

My confusion probably stems from not being familiar with whatever
specification defines the other rel values that have been proposed -
forgive me if there's an obvious connection that I'm missing. Does the
inconsistency of defining our own rel value in this case really
outweigh the ambiguity of using "rel=self"? What are we trying to be
consistent with?

Gavin

[Mike Connor]

I don't think the new bit matters as much as the idea of it
representing the canonical location of the descriptor, which isn't
solely useful for update purposes.

DeWitt, do we have anything else to deal with here? Can we get this
rolled into Draft 4 ASAP?

-- Mike

[DeWitt Clinton]

Yes -- is consensus that "self" is okay then?  Unless I hear a strong objection (Gavin?) then I'm going to document it as such in Draft 4 by tomorrow.  I'll do this as part of a more general list of 'rel' values. 

We'll have to decide how much to document about how/when clients should refresh rel="self" urls, but I'm inclined to leave most of the implementation details to the vendors.  Let me get the draft text out and you guys tell me what you think.

-DeWitt

[Gavin Sharp]

I'm fine with self. I've answered my own question about where it comes
from - I wasn't really aware of its use in the context of RSS/Atom, so
it seemed rather arbitrary and confusing.

Gavin

[DeWitt Clinton]

Hi all,

Reopening an old thread, specifically about our proposed rel="self" value. 

This morning Google, Microsoft, and Yahoo announced support for rel="canonical" in HTML.  See:

  http://searchengineland.com/canonical-tag-16537

  http://googlewebmastercentral.blogspot.com/2009/02/specify-your-canonical.html


So, should we change our draft to match what will presumably become standardized in HTML5 (http://www.whatwg.org/specs/web-apps/current-work/#linkTypes), or, as planned, stay consistent with Atom's already-standard 'self'?

My bias to stick with the latter ('self') because people here are already building on it, but I felt a passing obligation to at least ask.

-DeWitt

[Gavin Sharp]

We've already implemented support for rel="self" update support in
Firefox 3.1-pre builds, for what it's worth. The feature will be
included in Firefox 3.1 beta 3 which should be out in the next few
weeks or so. It's not too late to change the attribute we check before
we ship Firefox 3.1, assuming we can reach agreement relatively
quickly.

An OpenSearch description file is only useful insofar as it describes
how to retrieve other information, and isn't likely to be accessed via
more than one URI, so the "canonical URI" concept doesn't have the
right semantic in my mind - but that's just quibbling. I don't really
feel strongly about this, so I suppose by default I'd favor the status
quo.

Gavin