If an extension integrates with Weave it will need to check whether
Weave is there and whether it provides a compatible API. Here is how I
do it right now:
try
{
let resProtocol = Components.classes["@mozilla.org/network/
protocol;1?name=resource"]
.getService
(Components.interfaces.nsIResProtocolHandler);
if (resProtocol.hasSubstitution("weave"))
loader.loadSubScript('chrome://adblockplus/content/
weaveIntegration.js');
}
catch (e)
{
dump("Adblock Plus: Error loading Weave integration code: " + e +
"\n");
}
The idea is - if Weave isn't there, don't even try to load the Weave
integration code (will save a little on startup time). If Weave is
there, load the code "blindly" - if it is an unknown Weave version
with a different API this will fail (typically due to some class not
being defined) and we simply report an error to console, nothing bad
happened.
The big question, is this approach good enough? Might there be
incompatible API changes, yet all the key classes stay in place and
engine registration succeeds? Should I check Weave version explicitly
instead? The problem with that - I cannot be sure that Weave 0.4 will
still be compatible for example. It might be compatible but I won't be
able to change the version check once I release Adblock Plus. Release
a new Adblock Plus version every time a new Weave version comes out? I
doubt that would work, I already try that with Songbird - mostly
without success.
We haven't locked down the internal API yet, so it might make sense to
look at the weave version. Weave defines the version in install.rdf,
and also as a js constant in resource://weave/constants.js
Dan
On May 16, 2009, at 2:26 PM, Wladimir Palant wrote:
> If an extension integrates with Weave it will need to check whether
> Weave is there and whether it provides a compatible API. Here is how I
> do it right now:
> The idea is - if Weave isn't there, don't even try to load the Weave
> integration code (will save a little on startup time). If Weave is
> there, load the code "blindly" - if it is an unknown Weave version
> with a different API this will fail (typically due to some class not
> being defined) and we simply report an error to console, nothing bad
> happened.
> The big question, is this approach good enough? Might there be
> incompatible API changes, yet all the key classes stay in place and
> engine registration succeeds? Should I check Weave version explicitly
> instead? The problem with that - I cannot be sure that Weave 0.4 will
> still be compatible for example. It might be compatible but I won't be
> able to change the version check once I release Adblock Plus. Release
> a new Adblock Plus version every time a new Weave version comes out? I
> doubt that would work, I already try that with Songbird - mostly
> without success.
On May 20, 9:48 pm, Daniel Mills <thun...@mozilla.com> wrote:
> We haven't locked down the internal API yet, so it might make sense to
> look at the weave version. Weave defines the version in install.rdf,
> and also as a js constant in resource://weave/constants.js
Next time Weave updates all Adblock Plus users will automatically lose
syncing, until an Adblock Plus update is released. Is there a way to
get an advanced warning before a Weave release (at least two weeks in
advance) to test compatibility? If not - Weave is a very nice tool but
maybe my support for it was premature and I should remove it again (or
at least extract it into a separate extension that will have visible
dependencies on both Adblock Plus version and Weave version).
On May 22, 2009, at 1:16 AM, Wladimir Palant wrote:
> On May 20, 9:48 pm, Daniel Mills <thun...@mozilla.com> wrote: >> We haven't locked down the internal API yet, so it might make sense >> to >> look at the weave version. Weave defines the version in install.rdf, >> and also as a js constant in resource://weave/constants.js
> Next time Weave updates all Adblock Plus users will automatically lose > syncing, until an Adblock Plus update is released. Is there a way to > get an advanced warning before a Weave release (at least two weeks in > advance) to test compatibility?
For releases (that go on AMO) - yes, we release development snapshots generally on a weekly basis (though we haven't done one in a few weeks).
> And it'll auto-update to the newest snapshot release.
Sorry, that doesn't really answer my question. I can build Weave
myself from Mercurial, not a problem. The problem is telling when I
need to retest my code (and create a new release because that would be
the only way to update compatibility info). I wouldn't want to do that
weekly. I would rather prefer a message (on a mailing list, blog or
whatever) - "we are going to have another major release in two weeks
and here is our beta version, we also won't change the API any more
for that release."
> On May 23, 1:07 am, Daniel Mills <thun...@mozilla.com> wrote:
>>> Is there a way to
>>> get an advanced warning before a Weave release (at least two weeks
>>> in
>>> advance) to test compatibility?
>> For releases (that go on AMO) - yes, we release development snapshots
>> generally on a weekly basis (though we haven't done one in a few
>> weeks).
>> And it'll auto-update to the newest snapshot release.
> Sorry, that doesn't really answer my question. I can build Weave
> myself from Mercurial, not a problem. The problem is telling when I
> need to retest my code (and create a new release because that would be
> the only way to update compatibility info). I wouldn't want to do that
> weekly. I would rather prefer a message (on a mailing list, blog or
> whatever) - "we are going to have another major release in two weeks
> and here is our beta version, we also won't change the API any more
> for that release."
