Subscriptions and compatibility with 0.5

0 views
Skip to first unread message

earth2marsh

unread,
Jul 7, 2009, 12:08:53 AM7/7/09
to ubiquity-firefox
I've updated a couple of scripts I've published so they are compatible
with 0.5, but then I published the new source to the same URL…

So haven't I essentially "broken" the script for people who haven't
yet made the jump to 0.5? Is there a "recommended" way for 3rd party
scripts to handle this?

[For those of you running 0.5, the very simple percent encode/decode
script is at http://earth2marsh.com/ubiquity/ ]

And just 'cause I'm curious, would it be technically possible to
create a command for 0.5 that transformed old commands on the fly (say
a verb called "compat")? So I could invoke ubiq and type "compat OLD-
COMMAND-NAME stuff-i-want-it-to-act-upon" and it would sort out the
messy bits?

I'm guessing this is a non-trivial problem, or else it would have been
built into the architecture of 0.5…

"mitcho (Michael 芳貴 Erlewine)"

unread,
Jul 7, 2009, 2:11:56 AM7/7/09
to ubiquity...@googlegroups.com
> So haven't I essentially "broken" the script for people who haven't
> yet made the jump to 0.5? Is there a "recommended" way for 3rd party
> scripts to handle this?

For the time being, I don't think there's anything we can really
particularly do on the command feed-side but, as is being discussed
and Aza just presented some thoughts on [1], it's currently looking
like we'll push a 0.1.9 release for the 0.1.x users which will tell
them when they try to subscribed to a 0.5 API command that they must
use Ubiquity 0.5.

[1] http://vimeo.com/5483375

This should help with these users you describe who currently could try
to subscribe to your command and "bad things" would happen.

> And just 'cause I'm curious, would it be technically possible to
> create a command for 0.5 that transformed old commands on the fly (say
> a verb called "compat")? So I could invoke ubiq and type "compat OLD-
> COMMAND-NAME stuff-i-want-it-to-act-upon" and it would sort out the
> messy bits?
>
> I'm guessing this is a non-trivial problem, or else it would have been
> built into the architecture of 0.5…


This is indeed a non-trivial problem, but we're trying to support
command authors during this transition with a command conversion
tutorial [2]. This tutorial will walk through the conversion process
(hopefully in an easy to understand fashion). And if it's not easy to
understand, please let us know! I'd love to get some feedback on it.

[2] https://wiki.mozilla.org/Labs/Ubiquity/Parser_2_API_Conversion_Tutorial

mitcho

--
mitcho (Michael 芳貴 Erlewine)
mit...@mitcho.com
http://mitcho.com/
linguist, coder, teacher

earth2marsh

unread,
Jul 7, 2009, 3:16:49 PM7/7/09
to ubiquity-firefox
> For the time being, I don't think there's anything we can really  
> particularly do on the command feed-side

What about adding an @ rule, like "@branch 0.1" in a commented section
preceding any code (a la greasemonkey scripts). Perhaps a second
commented @branch rule could then denote code for 0.5 without having
to have multiple URLs for the same command? It's not terribly elegant,
but it might suffice. You could require this for 0.5 and beyond, and
if no @branch is found, assume it's pre-0.5.

Or considering that extension XPI's have a space for version
compatibility—couldn't we borrow their model?

> This tutorial will walk through the conversion process  
> (hopefully in an easy to understand fashion). And if it's not easy to  
> understand, please let us know! I'd love to get some feedback on it.

I used that guide when converting my simpler commands, in preparation
for migrating the more complicated chart ones here:
http://earth2marsh.com/ubiquity/charts.html

When I get some free cycles, I'll update those commands and make note
of anything confusing in the tutorial.

Marsh

Gary Hodgson

unread,
Jul 7, 2009, 3:53:41 PM7/7/09
to ubiquity...@googlegroups.com
For what it's worth this is my solution to the upcoming 0.5 release.  It's certainly not elegant, but it works, and it means I don't have the hassle of managing two versions of the commands whilst people migrate.

var isParser2 = function(){
var prefs = Components.classes["@mozilla.org/preferences-service;1"].getService(Components.interfaces.nsIPrefService);
var branch = prefs.getBranch("extensions.ubiquity.");
return (branch.getPrefType("parserVersion") != 0) ? branch.getIntPref("parserVersion") == 2 : false;
}

if (isParser2()) {
/* Parser 2 version of the CmdUtils.CreateCommand calls here */
/* ... */
} else {
/* Parser 1 version of the CmdUtils.CreateCommand calls here */
/* ... */
}




2009/7/7 earth2marsh <marsh.g...@gmail.com>

"mitcho (Michael 芳貴 Erlewine)"

unread,
Jul 7, 2009, 7:42:18 PM7/7/09
to ubiquity...@googlegroups.com
Ah, very slick. :) Thanks Gary.

earth2marsh

unread,
Jul 7, 2009, 8:37:24 PM7/7/09
to ubiquity-firefox
Gary, that's pretty clever! Thanks for sharing--great idea for a work-
around.
Reply all
Reply to author
Forward
0 new messages