I'm currently developing a browser plugin for MacOSX 10.6, and am planning to use the netscape API for portability across browsers and architectures. According to Apple's documentation, as of 10.6 such plugins run out-of-process to improve the integrity of the browser session. What I'm concerned about is the following directive they give in the documentation:
Use platform APIs sparingly. Wherever possible, you should use new
plug-in APIs to do what you need. If no such APIs exist, file bugs requesting them.
I'm not sure what the nature of this directive is. Is this advice to improve portability of the plugin, a reminder that accessing the operating system's other APIs can open up the possibility of crashing the client or corrupting a user's data, or an indication that access to the platform APIs is in some way "broken?"
Its portability advice. The NPAPI is, although not officially standardized, fairly stable and already wraps some platform specific APIs for you.
If you try to use NPAPI whenever possible, you avoid quite some porting as e.g. it happened relatively recently with Apple effectively deprecating Carbon when transitioning to 64 bit.
Related
I'm in the process of porting an application to ChromeOS with the requirement that it should look and feel as native as possible. This means in particular that it should allow things such as multi-monitor support and USB support.
One possibility would be to implement it as a web application (since we have already a web client), but in this case I would need to add support for native features (again, multi-monitor support and USB device access), so I wonder what needs to be done in this case. My wild guess as a ChromeOS developer newbie is that I would need to extend the code with ChromeOS JavaScript features, and I don't know if this is possible.
Another possible approach would be to write an Android application, since I see that ChromeOS added support for Android applications (in this case I would have to write the code from scratch).
Finally, another option would be to write native code, which could be possible for example relying on a Crouton development environment, and reuse the code of a native C application.
What approach would you recommend to build a ChromeOS application starting from a web application or from a native one?
What approach would guarantee access to native features (multi-monitor support and USB)?
I discovered two APIs which should help with multi-monitor support:
https://developer.chrome.com/extensions/windows
https://developer.chrome.com/apps/system_display
The system.display API allows one to discover and monitor the current monitor layout, while the windows API allows one to create several windows in the same application. By combining these ones I should be able to create a window for each monitor in case I go with the chrome implementation route.
Given that I already have a native implementation for Linux, Crostini (as opposed to Crouton) is also very appealing since it provides a deeper level of integration with virtually no changes to the code and no need to maintain two different versions of the web client, with the only downside that it requires the user to create a Linux environment and manually install the application, also it is not supported on all chromebook devices and on many it will be never supported.
I still need to check what is the performance overhead. Also the level of integration with USB I/O might be higher than the one achievable by using the chrome API.
Recently I have worked using WebRTC and I'm wondering if it would make more sense to implement a Real Time Communication open standard at a native level.
Let's say that instead of a web browser API we have a native API that any native app, including the browser can leverage.
Part of the promise of WebRTC is to have RTC on the browser without plugins but why stop there, why not have RTC on any device with media capabilities without plugins. There are many devices with media capabilities that will not run a web browser, e.g., wearables. It seems to me that the browser itself has become the plugin and I think we need to get rid of it as far as RTC is concerned.
It sounds like OpenWebRTC is going in a similar direction but so far they are only working inside the browser.
Are there open standards for native RTC? So far it looks like RTCWeb is only concerned about the browser.
Are there any projects/initiatives for native implementations of an open standard for RTC?
webrtc definition. webrtc is stuck into two parts, complementary but separated. the W3C consortium is standardizing a JS API for browsers named webRTC. The IETF is standardizing the underlying protocols and what happen on the wire for interoperability, it is named rtcweb.
the IETF's rtcweb group defines everything you need to interoperate with a browser, without being a browser yourself, i.e. for gateways, devices, .... It has been made explicit at the latest meeting in hawaii last november, and there is for example a corresponding draft.
On the client side, the implementation of webRTC JS API is done on top of c/C++ implementations. Those "native" (as in non-browser, C/C++) APIs can be use directly for servers, embeddable devices, gateway, ect, or can also be wrapped in different languages (obj-c, java) to provide "native" (as in mobile native) APIs.
Note that BOTH openWebrtc.io and webrtc.org have a full implementation of webRTC in C/C++ that you can use. openWebrtc provides iOS wrappers, and webkit wrappers (for safari), but do not provide data channel support, ORTC API support, nor compile under windows. webrtc.org supports all desktop OSes, and provide wrappers for both iOS and Android. The build tools are specific to google's chrome though, unlike openWebRTC which uses standard auto tools, github, ...
HTH
Currently there is no effort in this direction. The guys in the webrtc standardization committee have their hands full standardizing just the javascript API. As you know the current spec is not final and is currently still worked on. And now ORTC will generate even more work.
There are many reasons why no one is currently trying to standardize any form of native RTC. Here are some that come to my mind:
What exactly is native? Javascript is native for the browsers. The chrome version of webrtc is in C++ but the OpnWebRTC one is in C. Android developers use mostedly Java, iOS developers use ObjectiveC. Should there be standards for all these languages? That's going to take forever.
As I said standardization committee already have their hands full.
There is still quite a lot of experimentation that goes on with WebRTC. Standardization may prevent this.
The API of the native libraries tend to be very similar to the JS API.
All,
I'm attempting to estimate the effort to port an app developed on Windows (.NET) to Linux (Mono). I came across the MoMA tool, which attempts to look through my .exe and find potential areas of incompatibility. Most of my issues appear to be centered around get/set of network settings, getting network info, etc. (Object ManagementBaseObject.get_Item and set_Item. etc).
In almost all of the cases, the Mono functionality is listed as "ToDo". For estimation purposes, is it safe to assume most/all of these have some kind of workaround? I would imagine this type of basic networking support must be included in the latest version of Mono. Or should I assume none of this is currently available and I would be stuck waiting for it to be implemented (or be forced to implement it myself)?
Thanks,
Dan
First,see Mono Compatible Networking/Socket Library. Also,take a look on Cross-Platform Network Applications with Mono. You can start with C# Network Library.
I saw that the Clang 3.0 port includes Objective-C as a development language, and furthermore, I also found this port "libobjc2-1.6" (Replacement Objective-C runtime supporting Obj-C 2 features) and "ofc-0.8.1_5" (The Objective-C Foundation Classes library).
Let's say we are considering to use Objective-C on FreeBSD to develop a web-based application (vs. using Java and running it on Tomcat/Glassfish), how do we approach it?
Does Objective-C development actually work on FreeBSD (9.0)?
What are the things (frameworks/library) to download and install?
What IDE?
As I mentioned that let's say we intend to develop a web application, what are the library?/libraries (We also saw that there is "GNUstepWeb" - successor to WebObjects - is this the web library we should consider? Is this the ONLY ONE - what about other alternatives? Further, can GNUstep/GNUstepWeb compile under Clang 3.0 or make use of those Objective-C ports ("libobjc2-1.6" and "ofc-0.8.1_5") mentioned above? Are those ports relavant?
Has anyone successfully done a web application project development on FreeBSD using Objective-C (and deployed on FreeBSD)?
Note: Web-based applications means it takes in HTTP (RESTful) calls and talks to a database (for traditional and/or NoSQL databases).
There is http://cocotron.org, a port (more like re-write) of Apple's runtime for Objective-C.
I still could advice against using ObjC for web stack. I did that previously, and I must say that it involves a big chunk of pretty common code that you will need to implement for basic HTTP server functionality.
Also, Cocotron is not really that fast (as a runtime). It's ok for desktop applications, but web world is much more restrictive.
I am writing a library supporting this using FastCGI to interface the server called CGIKit (https://github.com/xcvista/CGIKit) and it works on GNUstep instead of Cocoatron.
you may look at sope and sogo http://sope.opengroupware.org/en/build/thirdparty.html
Someone seems having success building Objective-C program for FreeBSD 9.x
You don't need to worry about the IDE if you don't mind using Apple. It would be possible to write on Mac, and run on FreeBSD. (personally I think this is the best of both world) IMO, if there's a server OS with Objective-C ready, FreeBSD will be first one.
More serious problem is libraries and frameworks. We don't have much options in Objective-C for web server development even on OSX. But we can wrap existing C/C++ libraries, (just as like many great node.js, Python, Ruby libraries do) and I think we may can get bunch of options with small efforts.
Some people worry about security. And I always wonder how many foundational programs on the network are written in C/C++ and other languages.
In his blog post “Using Objective-C on the server” Graham Lee describes how to set up a minimal GNUStep-WebApp. Obviously, the build instruction for GNUstep-make would differ, but other than that this seems like a nice starting point.
He wrote several other posts (jQuery, AJAX) further exploring GSW.
I'm looking to use Chromium OS for a specific business application, but I need access to local serial and USB ports. My reading of the Chromium docs says NPAPI plugins are not supported in Chrome OS, only PPAPI (Pepper). I'm a bit confused about PPAPI, as all docs talk about this in the context of Native Client, which as it's a sandboxed environment, cannot access local resources.
So my basic question is: Is it possible to write a PPAPI browser plugin that will work like a regular NPAPI browser plugin to access local resources?
Currently, no. NPAPI plugins are on the way out, Native Client is a sandboxed environment, and Pepper's interfaces are designed to mirror those available elsewhere on the web platform (e.g. Javascript). So a good place to look for future interfaces would be draft web standards and HTML5/JS addons, e.g. for gamepads (https://wiki.mozilla.org/GamepadAPI) or cameras (http://developers.whatwg.org/video-conferencing-and-peer-to-peer-communication.html )