Re: Proposed W3C Charter: Web of Things Interest Group

[L. David Baron]

On Monday 2016-06-20 01:38 -0700, mar...@marcosc.com wrote:
> On Tuesday, June 14, 2016 at 7:06:39 PM UTC+10, David Baron wrote:
> 
> > Please reply to this thread if you think there's something we should
> > say as part of this charter review, or if you think we should
> > support or oppose it.
> 
> It seems to go off into the RDF/XML weeds and tries to mask itself as 
> something different to IoT (whatever that is). I think we should oppose it as 
> it seems that whatever the result is, will not be Web friendly (in the sense 
> that it won't work with web browsers, JS APIs, etc.).

So opposing it takes both a good bit of energy and a potentially a
good bit of political capital (in that it might reduce the
seriousness with which people take future objections that we make).
Do you think it's actually worth getting involved here?  If so,
would you be willing to help write the objection?

-David

-- 
𝄞   L. David Baron http://dbaron.org/   𝄂
𝄢   Mozilla  https://www.mozilla.org/   𝄂
 Before I built a wall I'd ask to know
 What I was walling in or walling out,
 And to whom I was like to give offense.
   - Robert Frost, Mending Wall (1914)


signature.asc
Description: PGP signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Notes about implementing DOM APIs in Rust

[Henri Sivonen]

Last week, people interested in the matter met to talk about
implementing DOM APIs in Rust. Here are my notes.

The summary of the meeting is that we shouldn't be designing bridge
framework type of stuff ahead of time and for the time being we should
instead address issues as they arise.

We shouldn't expect to be able to use Servo's implementations of DOM
APIs in a drop-in a manner in Gecko. Because Servo allocates Rust
objects on the JavaScript heap, but Gecko doesn't allocate C++ objects
on the JavaScript heap, the memory management arrangements of the two
engines are fundamentally different and, therefore, the same WebIDL
bindings won't work.

Additionally, it was discussed whether there should be Gecko-specific
WebIDL bindings. The conclusion was that there shouldn't be, at least
for now. Instead, when implementing a WebIDL-specified API in Gecko in
Rust, the existing bindings for C++ should be used and then the C++
code should call into Rust.

If it happens that the implementation of an API could be shared
between Servo and Gecko if it weren't for the binding incompatibility,
the implementation of the API should be abstracted away from the
binding so that both Servo-style and Gecko-style binding code can call
into the shared implementation.

As an exception to the general sentiment of not providing WebIDL
bindings for Rust in Gecko, there was agreement that we should
introduce the WebIDL annotation for requesting a USVString to be
exposed as a guaranteed-valid UTF-8 subclass of nsACString instead of
the usual UTF-16. The idea is that it should be easy to pass this
onwards to Rust and view the data as &str in Rust.

Additionally, there was some discussion about reference counting.
Implementing an XPCOM binding for Rust was not a popular idea and was
discarded. Still, it was considered important to be able to use
Gecko-style reference counting in a cycle collector-compatible manner
across the C++/Rust boundary. Specifically, we should introduce a
macro for implementing AddRef, Release and associated cycle collection
methods in Rust in a cycle collector-compatible way and we should
implement a Gecko-flavored replacement for Rc<> that calls Gecko-style
AddRef/Release as appropriate.

Now that I'm looking at the hand-written notes that I made in the
meeting, I notice that the above paragraph fails to say how the
AddRef, Release and associated cycle collection-related calls are
routed from C++ to Rust or from Rust to C++. There was some talk about
vtable hacks, but my recollection is that those got rejected along
with XPCOM. So as far as I can tell, we are left with the meeting not
concluding how exactly these calls across the language boundary.

(A remark of mine that was not discussed in the meeting and that I'm
just adding onto the notes now as hopefully relevant to the last
paragraph: If we don't want to hack vtables to make direct virtual
calls between C++ and Rust, one way to use C linkage and FFI but still
have the C++-side calls syntactically look like C++ method invocations
that fit into existing C++-side smart pointers (etc.) is to interpret
pointers returned from Rust as pointers to instances of a C++ class
whose methods do nothing but call FFI functions with "this" as the
first argument as seen in
https://github.com/hsivonen/encoding-rs/blob/master/include/encoding_rs_cpp.h
.)

-- 
Henri Sivonen
hsivo...@hsivonen.fi
https://hsivonen.fi/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposed W3C Charter: Web of Things Interest Group

[Benjamin Francis]

On 22 June 2016 at 17:18, L. David Baron  wrote:

> So opposing it takes both a good bit of energy and a potentially a
> good bit of political capital (in that it might reduce the
> seriousness with which people take future objections that we make).
> Do you think it's actually worth getting involved here?  If so,
> would you be willing to help write the objection?
>

Can we make suggestions about how to improve the charter rather than just
oppose it? I don't necessarily agree with the technical approach the group
is currently taking, but I do agree that the Web of Things could be a
valuable area for standardisation, as a layer of abstraction above various
incompatible IoT protocols which makes "things" linkable, discoverable and
interoperable via URLs.

Perhaps the effort should be more focused on use cases and real world
implementations before, as Marcos says, going off into the RDF weeds.

Ben 
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposed W3C Charter: Web of Things Interest Group

[Anne van Kesteren]

On Wed, Jun 22, 2016 at 7:14 PM, Benjamin Francis  wrote:
> Can we make suggestions about how to improve the charter rather than just
> oppose it? I don't necessarily agree with the technical approach the group
> is currently taking, but I do agree that the Web of Things could be a
> valuable area for standardisation, as a layer of abstraction above various
> incompatible IoT protocols which makes "things" linkable, discoverable and
> interoperable via URLs.
>
> Perhaps the effort should be more focused on use cases and real world
> implementations before, as Marcos says, going off into the RDF weeds.

We should just let them do their thing and do our thing elsewhere.
Otherwise you get another payments and nobody wins.

I recommend reading through http://dbaron.org/log/2006-08#e20060818a.
A decade old, but nothing changed.


-- 
https://annevankesteren.nl/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Notes about implementing DOM APIs in Rust

[Josh Matthews]

On 2016-06-22 1:05 PM, Henri Sivonen wrote:


Additionally, there was some discussion about reference counting.
Implementing an XPCOM binding for Rust was not a popular idea and was
discarded. Still, it was considered important to be able to use
Gecko-style reference counting in a cycle collector-compatible manner
across the C++/Rust boundary. Specifically, we should introduce a
macro for implementing AddRef, Release and associated cycle collection
methods in Rust in a cycle collector-compatible way and we should
implement a Gecko-flavored replacement for Rc<> that calls Gecko-style
AddRef/Release as appropriate.

Now that I'm looking at the hand-written notes that I made in the
meeting, I notice that the above paragraph fails to say how the
AddRef, Release and associated cycle collection-related calls are
routed from C++ to Rust or from Rust to C++. There was some talk about
vtable hacks, but my recollection is that those got rejected along
with XPCOM. So as far as I can tell, we are left with the meeting not
concluding how exactly these calls across the language boundary.


I do not recall dismissing exposing COM-compatible vtables from Rust.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Notes about implementing DOM APIs in Rust

[Jack Moffitt]

> I do not recall dismissing exposing COM-compatible vtables from Rust.

We must implement COM interfaces in Rust for Windows platform things*
already. Specifically I have macros that generate IUnknown which for
Windows COM includes AddRef, Release, and QueryInterface. For COM
interfaces with single inheritance, this isn't too bad. mystor has
also been hacking on similar things

jack.

* Specifically I've been doing it to get DirectWrite working
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Notes about implementing DOM APIs in Rust

[Bobby Holley]

Sure - it's just a question of whether this level of hackery is desirable
for integrating with the rest of Gecko (a platform we control). I suspect
that we can probably solve whatever use-cases arise in cleaner ways, but we
should wait for use-cases to appear first.

On Wed, Jun 22, 2016 at 10:33 AM, Jack Moffitt  wrote:

> > I do not recall dismissing exposing COM-compatible vtables from Rust.
>
> We must implement COM interfaces in Rust for Windows platform things*
> already. Specifically I have macros that generate IUnknown which for
> Windows COM includes AddRef, Release, and QueryInterface. For COM
> interfaces with single inheritance, this isn't too bad. mystor has
> also been hacking on similar things
>
> jack.
>
> * Specifically I've been doing it to get DirectWrite working
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

MXR permanently offline, please transition to DXR

[Lawrence Mandel]

Mozilla Cross-Reference, better known as MXR (https://mxr.mozilla.org), was
taken offline on June 13, 2016, to investigate a potential security issue.
After careful review of the codebase, we have decided to accelerate the
planned transition from MXR to its more modern equivalent, DXR (
https://dxr.mozilla.org), instead of bringing MXR back online. As far as we
know there was never a security compromise, but the unsupported legacy
codebase (forked from an old version of LXR) would require significant time
and effort to rewrite and bring up to spec.

Our transition plan is as follows:


   -

   Add an interstitial web page at https://mxr.mozilla.org that displays a
   best-guess URL for the equivalent https://dxr.mozilla.org file data.
   This will help interactive users retrieve data from historical links in
   applications like Bugzilla.
   -

   Redirect certdata.txt and effective_tld_names.dat to their canonical
   source code repositories instead of DXR. All other search queries and
   automatic pulling of raw files by third parties will no longer be supported
   at the https://mxr.mozilla.org URL.
   -

   Index the remaining repos listed in MXR in DXR for data parity, using
   bug 1281443 to track progress. Repos will be indexed in the order listed
   unless otherwise specified. If you need to prioritize the indexing of
   specific repos, please open a bug and block against bug 1281443.


Our expectation is that the interstitial page will be in place and the
following remaining high-priority repos will be indexed by June 24th, 2016:

   -

   add-ons
   -

   servo
   -

   l10n


If you have concerns, questions, or requests, please open a new bug and
mark it as blocking bug 1281443 or add a comment to one of its existing
dependent bugs. Additional status updates will also be posted to bug
1281443 and its dependent bugs.

Lawrence
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Notes about implementing DOM APIs in Rust

[Andrew McCreight]

On Wed, Jun 22, 2016 at 1:05 PM, Henri Sivonen  wrote:

> Now that I'm looking at the hand-written notes that I made in the
> meeting, I notice that the above paragraph fails to say how the
> AddRef, Release and associated cycle collection-related calls are
> routed from C++ to Rust or from Rust to C++. There was some talk about
> vtable hacks, but my recollection is that those got rejected along
> with XPCOM. So as far as I can tell, we are left with the meeting not
> concluding how exactly these calls across the language boundary.
>

C++ CCed objects don't even all use COM. Maybe the existing non-nsISupports
CC infrastructure could be used for Rust objects. If that doesn't work,
adding explicit support for Rust objects to the CC, like we have for JS,
doesn't seem like it would be too difficult. The CC used to nominally
support arbitrary languages.

Andrew



> (A remark of mine that was not discussed in the meeting and that I'm
> just adding onto the notes now as hopefully relevant to the last
> paragraph: If we don't want to hack vtables to make direct virtual
> calls between C++ and Rust, one way to use C linkage and FFI but still
> have the C++-side calls syntactically look like C++ method invocations
> that fit into existing C++-side smart pointers (etc.) is to interpret
> pointers returned from Rust as pointers to instances of a C++ class
> whose methods do nothing but call FFI functions with "this" as the
> first argument as seen in
>
> https://github.com/hsivonen/encoding-rs/blob/master/include/encoding_rs_cpp.h
> .)
>
> --
> Henri Sivonen
> hsivo...@hsivonen.fi
> https://hsivonen.fi/
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Notes about implementing DOM APIs in Rust

[Henri Sivonen]

On Jun 23, 2016 1:33 AM, "Andrew McCreight"  wrote:
>
> On Wed, Jun 22, 2016 at 1:05 PM, Henri Sivonen 
wrote:
>
> > Now that I'm looking at the hand-written notes that I made in the
> > meeting, I notice that the above paragraph fails to say how the
> > AddRef, Release and associated cycle collection-related calls are
> > routed from C++ to Rust or from Rust to C++. There was some talk about
> > vtable hacks, but my recollection is that those got rejected along
> > with XPCOM. So as far as I can tell, we are left with the meeting not
> > concluding how exactly these calls across the language boundary.
> >
>
> C++ CCed objects don't even all use COM. Maybe the existing
non-nsISupports
> CC infrastructure could be used for Rust objects. If that doesn't work,
> adding explicit support for Rust objects to the CC, like we have for JS,
> doesn't seem like it would be too difficult. The CC used to nominally
> support arbitrary languages.

Non-nsISupports cycle-collected objects were brought up as what we should
do in a way that avoids XPCOM. AFAICT, in this case, the methods need not
be virtual, so if we wanted to use a vtable-based solution for
cross-language calls, we'd need to make stuff virtual because of the
cross-language call mechanism.

In the absence of cross-language inlining (LLVM on both sides), which I'm
told is not about to happen on Windows, the trickery with "this" to make
FFI look C++ish to the C++ caller should inline into a plain function call,
which should be preferable to a virtual call. (If we ever get
cross-language inlining with clang and rustc, the inlining opportunity
would be even better.)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform