semi OT: Android -> chrome native client in the browser

[Laeeth Isharc via Digitalmars-d]

> Thanks, I had not seen this, only the earlier hack where some 
> dev got the alpha version of ARC working on desktop OS's on his 
> own, which I thought about mentioning here but didn't.  I 
> figured it wasn't that important.

Yes - my judgement (acknowledging I am stepping outside of my 
area of core expertise) is that this might turn out to be very 
important indeed.

It's a slightly crazy situation today where you have to develop 
for the Mac, Linux, Windows, iOS, and Android - and it's not even 
all that comfortable to use one language for the different ports. 
  I acknowledge that there are choices that make it easier in some 
ways than this simplistic description, but none of these options 
from what I have read (but without experience so far) seem to be 
without their faults too.

[Tangent follows: We seem to be in a time when it pays to iterate 
rapidly.  My interest and experience is more on the enterprise 
(or at least commercial) side, and there it is a real pain to 
deal with repeated updates from applications (that always seem to 
break things in their interactions with other things on Windows 
machines).  I dealt with this personally in a similar way to a 
friend of mine who announced that he would be doing his own IT 
support henceforth and wished to be disconnected from the 
internal network and put on a DMZ.  (Partner at a tech asset 
manager, so he could).  But my point is - even at enterprise 
level, where it's a less obvious domain - some possibility that 
there are gains to be had (with appropriate restrictions, no 
doubt).

On the other hand, as an economist I believe that if a resource 
becomes free due to temporary abundance, human beings find a way 
to make use of it - but it takes time, and for a while people get 
into the habit of wasting things and have a rude awakening when 
it becomes rather less scarce (which may not happen gently, life 
being what it is).   I reckon that might be happening with memory 
usage and efficiency (if you act like I/O is the bottleneck, in a 
few years you can be sure it won't be any longer) - and until 
this is the new consensus, I adopt the position of a native code 
fanatic (as a multi-year trading view, not for a lifetime)].

> To be fair, they've actually done a lot to secure NaCl, unlike 
> ActiveX. ;) But yes, nobody uses the Chrome Store: they seem to 
> be trying to change that with ARC.

Yes - the concept was not necessarily mistaken, but their timing 
was off, and they (Microsoft) were not the right people to do it.

> If we have Android support for ARM, what is the advantage of 
> running in the browser on mobile devices?  This is never going 
> to work on iOS, because Apple doesn't allow full Chrome with 
> NaCl on iOS, only the Chrome UI wrapped around Apple's local 
> WebKit.  WP? :D

Not so much benefit to running in the browser on Android, 
obviously, except that I am somewhat pickier about the apps I 
install than the websites I take a look at, and probably this is 
true of many people.  Small frictions cumulatively have large 
consequences in an age of short attention spans, low future time 
orientation, and a lack of determination and nerve.

The benefit is you (if I have understood correctly - and I am not 
yet confident I have) can write something and have it be kind of 
usable across desktop platforms and android.  (Presuming they do 
open up the app store - it looks like for now perhaps it is 
opened up to Arc-weld ported apps, but only for chromeos - 
although it is not clear).  Of course you need to tweak according 
to the platform, and one shouldn't underestimate the trouble 
involved.  But being able to produce something usable quickly is 
quite valuable.

> As for converting native Android D apps to run on ARC, they 
> don't mention NDK, ie native, apps on their ARC webpage, but 
> the Chromium bug tracker shows that they're working on some 
> kind of NDK translation layer (funny that they hit the same 
> 64-bit long double issues on x86 that I did):

I think they might have it kind of working but maybe with 
glitches on native code.  I don't know how much slow down is 
involved in the translation.  Obviously ART/AOT changes many 
factors wrt relative advantage of native code (since it helps 
Java especially) - people say the difference is small, but the 
improvement in responsiveness doesn't seem small to me.  But that 
doesn't detract from the possibly very appealing idea of being 
able to write in one language across everything.  (except iOS).

> As you said, NaCl requires a modified compiler that restricts 
> the compiled binary to a more secure subset, so they appear to 
> be translating NDK-compiled or our D code to what the NaCl 
> sandbox accepts for it to work.

BTW here is what it looks like for x86:
https://developer.chrome.com/native-client/reference/sandbox_internals/x86-64-sandbox#x86-64-sandbox

Here is the API for a pure Chrome native client app:
https://developer.chrome.com/native-client/c-api

Here are some libraries that have been ported:
https://code.google.com/p/naclports/wiki/PortList

> But I'm skeptical that all these native workarounds in the 
> browser will ever really amount to anything- they haven't so 
> far- not because I don't believe in native, but because you're 
> often still stuck in the browser, ie the horrible HTML/DOM/js 
> stack.

But you are stuck because people use IE, Firefox, Safari etc?  Or 
something else?  It's worth taking a quick look at the native 
client demos - there was some python thing to fix to get them to 
work when I looked at a few months back, but I can't recall 
exactly what it was - a few lines needed to be changed for one of 
the python scripts used to install them.


> I suppose they want to take the Android runtime everywhere, 
> including the ART support that they're working on now 
> apparently, so given the great success of the Android platform 
> so far, who knows what will come of it.

I agree, although things don't change overnight.