[Development] URLs in QML/JS

[Alan Alpert]

On Mon, Jun 17, 2013 at 1:32 PM, Hausmann Simon
<Simon.Hausmann at digia.com> wrote:
> Hi,
>
> Here's one bit in QML that's been bothering me a bit, and I'd like to do
> something about it. But since it involves new API it requires a discussion and
> consensus.
>
> The problem: URLs in QML are inconsistent and hard to use. When reading a URL
> property (for example a C++ QObject with a property of type QURL), it is
> somethings wrapped as a string (when it happens so that the binding goes
> through the v4 interpreter), or it is wrapped as a completely opaque variant.
> It is hard to use, because the common things you may want to do with a url -
> such as inspecting the parsed portions or building a new URL - are impossible
> due to the lack of API. It appears that the most reliable way of for example
> verifying if a URL is of a certain scheme is to call toString on it and then
> apply a regular expression.

As I understand it, that's the current situation in browser JS too...

> I'd like to make URLs a better supported citizen in the world of QML's
> JavaScript, and it appears that a few options present themselves:
>
> (1) We could just create more or less a 1:1 API mapping of QUrl. A url object
> in JavaScript would continue to have a toString method, for convenient
> processing with functions that expect strings. But otherwise it would have
> properties such as scheme, authority, path. Unfortunately the formatting options of
> QUrl's C++ API don't seem to map very well to a JS property based API, so we'd
> have to stick with the defaults (PrettyDecoded?)
>
> (2) There appears to be development towards creating a specified URL JavaScript
> API in the world wide web. The most recent spec appears to be from the whatwg:
> http://url.spec.whatwg.org/ and it seems quite reasonable, as well as
> https://dvcs.w3.org/hg/url/raw-file/tip/Overview.html. However those are drafts
> and therefore likely subject to change, I think.
>
>
> Can anyone see a clear preference of (1) over the (2)? (1) is non-standard and
> likely to cause incompatibility issues in the future when integrating with
> third-party JS libraries. OTOH (2) may take who-knows-how-long until it finalizes.

I prefer (1), although it should ideally be a 1:1 mapping of
functionality with an API designed for QML. We'll have incompatibility
either way if it's a changing spec. We went with a draft spec for the
QtQuick.LocalStorage API and I don't think that's compatible with how
browsers implement local storage anymore. Better to add the
compatibility in a separate layer/step (which we'll need anyways for
browser objects).

> Also, would an "API addition" in that sense require a QtQml version bump (with
> regard to imports)?

Unfortunately, the QtQml import is quite separate from the language
version. An incompatible language change would require more than just
an import version bump. But so long as the new API has a superset of
String functionality and turns back into a QUrl properly when it
returns to C++, either approach should be compatible (we can probably
live with breaking the opaque variant case).

--
Alan Alpert