Opera extensions (widgets): dynamic config file

I have an Opera 11 extension, which has a background process and an injected script. These communicate very frequently with a remote server (not the webpage the user's viewing), using the background script's cross-site XMLHttpRequest capabilities.

I would l开发者_运维问答ike the URL of the server to be a preference, so that it can be modified by the user without editing the package. The config.xml file would good, for it accepts <preference name="serverUri" value="..." />. However, I would like the script to be able to update itself directly from the server (not through Opera's site), which can be achieved using <update-description href="http://myserver.com/client/update" />.

So what I would like to do is have the href attribute of the update-description element to be dependent on the value of the preference serverUri. I would imagine some syntax like this:

<update-description href="{$serverUri}" />

But I could not find any references to this kind of functionality. Is there some way to solve this?

It's not possible to use variables in the config.xml file as you've written and I don't think there are plans to add this.

I'm sure you know that preferences can be set not just with the preference element in config.xml but also using widget.setPreferenceForKey(value, key), but I don't think that solves your problem in this case.

The only workaround I can think of is if you have all your logic in an external script on your server and in your extension's local files (background script or injected script), just have a very simple couple of lines that reference your external script. Something like:

var script = document.createElement('script');
script.src = 'http://www.example.com/script.js';
document.body.appendChild(script);

You could then make the script's URL editable by the user and store it in widget.preferences.

EDIT by hallvors: This solution has serious drawbacks, see my comment below.

As far as I know this is not currently possible. It seems like a bit of an unusual use case, which could potentially be risky to implement, so it would be interesting to hear more about why you want to do this.