Re: The Revenge of the Geeks
Date: Sun, 27 Jan 2013 01:38:24 -0600
Message-ID: <ke2ljt$s5s$1_at_news.albasani.net>
On 1/26/2013 9:14 PM, Arne Vajhøj wrote:
> On 1/26/2013 6:04 PM, BGB wrote:
>> On 1/26/2013 3:34 PM, Arne Vajhøj wrote:
>>> On 1/26/2013 2:22 PM, BGB wrote:
>>>> dunno about an app working in a browser, I haven't personally really
>>>> looked much into this. the one thing I had noted which I felt might
>>>> make
>>>> this worthwhile was "Google Native Client", but given it is Chrome-only
>>>> at this point, this is a drawback (better if Firefox supported it, but
>>>> the FF people apparently oppose it).
>>>>
>>>> Adobe Flash sometimes seemed like a possible option, but isn't
>>>> particularly compelling, and the development environment apparently
>>>> costs money.
>>>
>>> Java applet, Flash, SilverLight, Google Native, JavaScript - there
>>> are plenty of options.
>>
>> yep, not saying that there aren't a lot of options here.
>>
>>
>> the main advantage of Native Client would be that it would be easier for
>> me to target it, mostly because it wouldn't require largely rewriting a
>> bunch of stuff (all the C parts of the project could be kept intact, and
>> compiled fairly directly, ...).
>
> Sure about that?
>
> I would expect Native Client to block a lot of code for
> security reasons.
>
from what I have read, it basically gives a POSIX-like API with OpenGL and a few other things, all running inside of its own sandboxed address space and filesystem.
if it supports this much (along with other basic things, like ability to build apps as multiple libraries, ...), most of my stuff should work without too much issue.
hopefully at least it is less of a hassle than dealing with the Android NDK, but who knows sometimes?...
(what partly killed my efforts on Android was not so much about getting things built, but mostly me not having any good idea how to make my stuff particularly usable via touch-screen UI, vs a mouse+keyboard UI, and not having many good ideas for UIs which would work well absent a mouse+keyboard interface). (a secondary issue mostly had to deal with concern over the often low hardware stats of typical Android devices as compared with a typical modern desktop PC, ...).
I did at least get as far as confirming that a lot of my stuff built and worked on ARM-based targets though.
one can probably assume it supports most basic things, but I have yet to find a good list of what parts of POSIX it supports. the lists I have found seem to mention including most parts I typically make use of (libdl, pthreads, calls like "mmap()", ...).
it was mentioned on the site that it does apparently lack BSD sockets though (annoying, but not a critical loss...).
granted, yes, not like code will probably be usable unmodified, but this is sort of to be expected in C land (you usually end up needing a bunch of #ifdef's and globs of target-specific wrapper code anyways).
thus far, nothing looks particularly unusual though...
>> a further limitation in the JS case though is that, given code is sent
>> and recompiled from text form, this puts effective size limits on it
>> (trying to give it a giant mass of trans-compiled code probably wont
>> work very well, and some other areas of JS give a lot of room for doubt).
>
> It si common today to develop JS source code with comments, long
> names, indentation etc. and then strip it before deploying to
> reduce size.
>
yes, but I mean, say you have a big C codebase, and try to trans-compile to JS. (say, you trans-compile an Mloc-range application to JS and try to get it loaded in the browser). even stripped, it would still be big.
the worry is that it could put a strain on the browser getting a large app downloaded and compiled.
then again, I guess a proof of concept would be if anyone can get something like Doom 3 trans-compiled to JS and running in a browser. Received on Sun Jan 27 2013 - 08:38:24 CET