Live data from Hacker News

Open Web Device

openwebdevice.com

91–97 of 97 posts

Re: Open Web Device

#91
post #89
post #81

Now that Chrome has made its way to Android, my guess is that Chrome Apps on Android are not far behind. I hope an app built for Chrome will work for OpenWebDevice & vice-versa.

Chrome Apps can use non-standard technologies (WebSQL, for example; and soon Dart), so they won't work in other browsers. In fact, some of those nonstandard technologies won't even work on Chrome when running on another type of device (NaCl apps will not run on ARM).

Though, to be clear, it should be easy to write a single app that works as both a Chrome app and a B2G/Firefox app, as long as you use APIs that work across both environments. (Chrome apps can access non-web-accessible APIs, but they don't have to.)

Re: Open Web Device

#92

This is actually a big deal. It is a step in the right direction to take care of the missing pieces of mobile app development. I really believe that in 5 years time, "application development" will be just assumed to be web app development and not desktop application development.

[deleted]

Re: Open Web Device

#93
post #60
post #43

Earlier quoted context omitted.

Isn't this similar to Apples initial idea with the first iPhone? Everything would be a "Web App"

More similar to the (initially announced) Palm Pre. It was supposed to be a device which runs Web Apps natively, and you write your applications in HTML + JS, using their "Mojo". Well, developers weren't having it, so they eventually allowed C / C++ as well. I'd predict the same with this device. Since it's running Linux kernel, I can pretty much guarantee that you will be able to run C / C++ apps on the device, and…

You didnt have to write them with Mojo, you could write them with any HTML/JS framework, or just roll you own. Mojo was just the one the Palm apps (Email, Web, Phone, ..) used.

And a vast majority of the apps for the platform used it for UI. C/C++ was generally only used for games ported from iOS to webOS, or when writing a custom plugin for some capability not provided by the service architecture.

C/C++ was allowed, but definitely not chosen "more often than not" on webOS. The UI for a vast majority of the apps was HTML/JS and using Mojo.

Re: Open Web Device

#94
post #29

Wow, what a thing to wake up to! At the heart of the Open Web Device is Mozilla's Boot2Gecko project. I just joined up with Mozilla on B2G a couple weeks ago and it's been an honor to work alongside so many amazing people, with a great goal: building a truly open mobile ecosystem. If you guys have any questions about B2G itself, feel free to ask and I'll do my best to answer.

I'm curious about b2g's security model but I haven't been able to find much of substance about it. Currently I'm pretty sure if you beat gecko you own any firefox tab that's open. Does that mean if you beat it on the phone you own the whole thing?

Re: Open Web Device

#95
Isn't this exactly the same as Google Chromium[1]? Boot a minimal OS and load a web browser to do all the heavy lifting. Don't get me wrong, I think doing it in the open is much better than behind closed doors, I just want to make sure that I'm not missing something.

1: http://www.chromium.org/chromium-os

Re: Open Web Device

#96

Doesn't support + signs in email addresses. Awesome. Does not inspire confidence in a platform that is based on internet standards, where email is an important part of communication.

You're right, if they left out the + sign on the beta keyboard UI they probably forgot all the calls to free(), WebSockets, and maybe CSS. Outlook is bleak.

Re: Open Web Device

#97
post #29

Wow, what a thing to wake up to! At the heart of the Open Web Device is Mozilla's Boot2Gecko project. I just joined up with Mozilla on B2G a couple weeks ago and it's been an honor to work alongside so many amazing people, with a great goal: building a truly open mobile ecosystem. If you guys have any questions about B2G itself, feel free to ask and I'll do my best to answer.

I had a couple of questions on how you'd implement things like Spotify or Dropbox (i.e. apps that download a bunch of files, or upload existing ones). And also about how apps would interact with each other (so that I can change out one SMS app for another, but have everything else continue to work). Oh, and will it support things like different keyboards? I love that on Android I'm not using the home screen, keyboard…

It's not possible to truly implement Spotify as there is no P2P in HTML5 yet - but see Chromium's efforts with WebRTC.

It's also not possible to implement Dropbox. When last I checked, IDB in Firefox is at least an order of magnitude slower than a KV implementation with direct posix access. Most importantly, there's no proper native crypto api, and no way to let a user open a file from within a web application, and have it open in a native application, polling the file for changes to sync the different chunks when the user hits CMD+S.

Would be great if Public Web Apps could push these two use-cases through and do so without undue delay. Here's a related thread started by Tim Berners-Lee: http://lists.w3.org/Archives/Public/public-webapps/2012JanMa...

Post reply on HN