I wanted to write a B/S project that client side uses ActiveX or Gecko to Communication with server via network socket. And any browser(ie/firefox/chrome/opera/safari) can use it.
If you want to support every major browser than you need to write both the ActiveX part (for IE) and the NPAPI part (for all other browsers). You can use support both technologies with one DLL though.
An easier way than implementing both yourself would be to use FireBreath, which does that for you and provides an abstraction layer over those APIs.
As you write native code with both technologies, sockets etc. can be used with both. The biggest limitations are with the UI side and permissions due to running code in a host application.
Note that XPCOM as a plugin technology is obsolete.
Related
First I would like to thank you (Stuart in special) for this amazing framework MvvmCross.
I have an application case that involves socket connectivity, and I would like to go with PCL for Android, WP7 and iOs.
Unfortunately, the PCL subset doesn't support sockets usage as is (I think NCL is supported only for Microsoft different frameworks).
I thought may be MvvmCross Plugin is the way to go, but still needs plugin implementation for each platform (I mean ...plugin.Droid, ..plugin.WP7 etc..) while it should be the same code at the end.
What do yo suggest?
Thanks
I thought may be MvvmCross Plugin is the way to go
Yes, this is exactly the sort of situation that Plugins were designed for.
I'd certainly implement this as a socket plugin:
The PCL part of the plugin would provided a socket interface, although it might also perhaps include some shared base class 'buffer copy' type functionality in the shared code too.
The platform specific socket implementations which handle raw socket connection and IO.
It's likely that these platform plugin additions would use quite a lot of file linking between several of the platform implementations - I'd expect there to be a lot of code that would have to be shared this way.
I think a sockets plugin will be quite a common requirement - so if you were to tackle this via open source, then you might find some willing contributors ... or, if you were to go closed source, then you might find some customers.
While no-one has open-sourced an IP network socket implementation at this stage, the Sphero project did include a Bluetooth socket example - albeit one that wasn't entirely network efficient in the way it communicated.
This Bluetooth socket code is open sourced within Ms-PL at https://github.com/slodge/BallControl/tree/master/Cirrious.Sphero.WorkBench/Plugins/Sphero
This Sphero plugin doesn't expose a PCL Sphero-Socket level API - instead at the plugin level it chooses to expose a Sphero-Robot level API.
With the benefit of hindsight (a wonderful thing), if I implemented this again then I'd implement:
a bluetooth serial port plugin exposing bluetooth scanning, connecting and socket streaming
an additional PCL library which consumed the plugin to drive the robot - this perhaps might be called a plugin but would not have any non-PCL code within it.
I want to develop a simple windows manager, but do not know which library to use. Requirements:
Take advantage of the existing high-level libraries to deal with fonts, images. Like GTK+, Clutter, GDK. But keep the design-relevance things out, which libraries should I use? Because I tried to use XCB, which is really painful. And I've heard about Wayland, and if I write it in XCB, it wouldn't be portable to Wayland.
I've read some posts on WM development, typically use XCB and Xlib, I think they are too low-level and I don't want to repeat others work. I want a more user-friendly WM, but keep simple and flexible.
The biggest issue is not the library to use. It is the complexity of the requirements, as dictated by ICCCM and EWMH.
A standard compliant window manager is quite complex, because the standards defining it are complex, and because the X11 protocol is complex.
You might fork an existing WM instead.
But any library capable of X11 protocol exchange can fit the bill.
and I am not sure that Wayland has window managers
I'd split the project in a (low-level) window manager on top of the core X11 libraries, and a high-level part implementing the UI to control the window manager, utilizing whatever toolkit you feel comfortable with.
The difficulty in using a toolkit is that these are not designed to be used from inside a window manager, i.e. the toolkit might expect to be able to send a message to the window manager and receive a reply without returning to "user" code in the middle.
Plus, this allows some more flexibility when using the window manager from different environments -- desktop integrators may choose to rewrite some of the control UI to better match the rest of the system, leaving the core service unaffected.
You can't use a high-level GUI toolkit to develop a window manager. These GUI toolkits are independent of the window manager and don't have any way to communicate directly with it - only in the ways defined by the standards.
I am going to implement an easy-to-use and eye-catching graphical user interface for management and configuration of an ethernet switch which has a flash (of just 16 MB) mounted in it, which will have an embedded linux, some specialized softwares, CLI and GUI.
I think, I should go for a web-based graphical user interface so that an admin can access it using the switch's IP. At client side I am thinking of using HTML5 or HTML4 with Javascript as GUI developed in Flex will probably take much more flash space.
However, I don't have a clear idea of server side technology to be used. Should I go for mini-apache for embedded systems with PHP (as I am familiar with Apache+PHP on x86 systems)? or is there a better alternative?
Also, should I go for a MVC type of architecture? Are there some great MVC frameworks developed for embedded systems?
Update:
Basically, I only need to provide a GUI on top of a CLI running on switch. Basic workflow of the application will be something like:
User access GUI through a web interface
User performs an action on GUI
A CLI command corresponding to the action performed is sent to the
server (running on switch)
Server runs the CLI command on the switch
Server returns result of the command back to GUI
You could use an HTTP server library like Onion (in C), GNU libmicrohttpd (in C), or Wt (in C++) to make your own specialized HTTP server (embedded inside your device).
You could also use Ocsigen in Ocaml for the same purpose.
I don't think that embarking a complete HTTP server (apache, or perhaps better lighttpd) with a PHP stack makes real sense on an embedded device (the code stack would be much bigger). On such a device the performance does not matter much (you won't get thousands of HTTP requests per second), but the code space (and process space, ie memory consumption) is quite important. (And the specialized web server solution I am suggesting uses only compiled code, which would run faster than interpreted PHP).
If you insist on having a lighttpd or apache web server in your device -which I believe is wrong-, you could make your application a FastCGI application (and code it in C, C++, Ocaml, ...).
As Simon Richter commented, you could consider making it (also) an SNMP service.
I just came across Google Native Client
Now, it looks really interesting that they ported Quake to run on a Browser and you can run C++ code on a browser to process things more quickly, but I am trying to understand, what is the practical usage of NaCl?
What is the vision behind this by Google? To run software as a service on their "cloud" OS..err browser?
For example: Run Photosphop CS 5 on your browser?!
Anything you can do with ActiveX, but far more secure.
Elaboration:
Google Native Client allows you to run machine code locally and natively, but sandboxed insofar as only allowing access to protected memory regions and disabling exploits in the machine code relating to processor errata (certain sequences of machine code operations which act strangely on particular processors). Additionally, certain APIs are available (such as OpenGL) and there is interprocess communication with Javascript running with the page, allowing webapps which have a fast, powerful native backend.
It would be quite difficult to use the Win32 API to generate any native windows or controls with Google Native Client, whereas it'd be probably a bit easier with ActiveX. However, ActiveX is generally used with things like "Quake Live" to provide a fast, native experience for the player, and additionally for Internet Explorer 'plug-ins' -- the Flash plug-in is ActiveX, for instance, and uses native code (i.e., the plugin is compiled to machine code).
Is it possible to write a mobile application with J2ME and whenever we want to implement a functionality not offered by J2ME call native mobile API ? (kind of like what is done with .NET, whenever you need something not provided, you just call the Win32 API from the .NET platform).
While JNI is not officially supported in J2ME, the Symbian implementation of J2ME obviously uses something very similar.
Since most J2ME APIs have a corresponding Symbian OS C++ API, what Symbian did (a lot) is develop adaptation layers between the 2.
Between that and the new modular architecture of the IBM J9 virtual machine (from Series60 3rd edition feature pack 2 onward), it is technically possible to add a new API to the virtual machine without actually needing to recompile most of a handset firmware.
However, third party developers simply are not allowed to do it without a lot of help from the handset manufacturer.
A loopback socket connection is the solution that people have tipically implemented to transfer data accross the language barrier. Large-scale deployment is not the easiest task, though, as you technically need to install 2 applications on the device. Once you understand the threading model of the Symbian J2ME implementation, you also realize how ugly and inefficient a hack it is.
When you reach that kind of issue, it's time to learn Symbian OS C++ and do it right.
No. That's not possible with Java ME.
Only sort of. Actually it is possible but not directly. You can write a native server that listens on a local socket and send requests to it from your Java MIDlet. Someone even released a framework to do this called MIDP-JNI (as opposed to real JNI). Obviously the form of the solution imposes some limitations on what you can do with it but it isn't actually impossible.
Be aware that using this approach can make your application much more complex to debug.
If you are specifically looking out for Nokia/Symbian, then APIBridge http://wiki.forum.nokia.com/index.php/J2ME_API_Bridge_Interface could be a solution. Typically it is the 'official' version of 'native server on local socket' kind of thing. The APIBridge is 'extensible' & you can write your own 'plugins' for your suitable 'low-level' task.