What technology, frameworks, programming languages are involved? Must support for tcp inbound and outbound connections, read webcam and mic data.
Browser plugins have access to the operating systems native APIs, so there is no major difference to a stand-alone application regarding camera-, audio- and network-access. What you have to be aware of though is that your code might run in a less privileged process.
For Internet Explorer you will have to write content extensions, specifically ActiveX controls, using C++. For all other browsers you will write NPAPI plugins C++ or C.
On Windows you can combine the two plugin types into one DLL. FireBreath does that, which you should look into as it already abstracts over the browsers (and other problems) for you.
Related
I've been looking into writing command line tools that interact with a web app recently, e.g a command line tool that orders a Jimmy Johns sandwich.
I can think of 2 approaches to this:
Socket programming and direct http input/output
Opening up chrome invisibly and running JS scripts on it
What are the advantages / disadvantages of each method? Which one would you recommend? Are there any other (possibly better) methods to accomplish this?
Advantages/Disadvantages:
Socket programming: lean but manual.
Chrome: not lean but can use JS.
If the interface is RESTful, there are plenty of light-weight clients that give you both leanness and high-level operation.
This article covers communicating with RESTful APIs using python and concludes by recommending the tool "requests".
The WebSocket protocol provides a way of creating web applications that support real-time bi-directional communication between clients and servers. Part of HTML5, WebSocket makes it much easier to develop these types of applications than the methods previously available. Most modern browsers support WebSocket including Firefox, Internet Explorer, Chrome, Safari, and Opera, and more and more server application frameworks are now supporting WebSocket as well.
There is some benefits if you use the websocket with https://github.com/Atmosphere/atmosphere
Hope this would help.
This is a copy of a post I've sent to the ZeroMQ mailing list. However, the question is raises it not specific to ZeroMQ, but more generally regarding the need for a 'mapping' layer over the networking functionality provided in WinRT to provide a more normal 'Berkeley Socket facade' for C++ code when compiling against WinRT:
Hi all, I've used ZeroMQ in a mobile app (see http://www.ibuzzedfirst.com ) previously, for the iPhone and Android versions, as those platforms support native/C++/Socket development, and therefore ZeroMQ.
For the WindowsPhone 7.5 (OS 7.1) version, I had to re-implement any required ZeroMQ functionality from scratch, as WinPhone 7.5 only supports C#, not C++ (it's effectively a C# Silverlight App). Also, WinPhone 7.5 only provides its own 'version' of Socket support ( http://msdn.microsoft.com/en-us/library/sb27wehh%28v=vs.95%29.aspx ) which only support Async versions of functions, e.g. ConnectAsync, SendAync, ReceiveAsync etc. However, the lack of C++ made this a moot point.
As such, for the WindowsPhone 7.5 version, I restricted the app to 'client' (Contestant) functionalty only, and didn't implement the 'server' (Quiz Master) part. This was because the client part of the app only sends and receives requests, replies and subscriptions to the server, whereas the server utilises the inherent multi-threaded multi-user functionality of ZeroMQ. It was (relatively) simple to recreate the ZeroMQ transport protocol/headers for client use, and use the WindowsPhone Socket support to provide comms.
Ok, now I'm looking at porting the app to WinRT on Windows 8. (The desktop/tablet version first - the Windows Phone 8 RT SDK isn't out yet, but will be similar). The good news is that C++ is supported in WinRT, yay! (Actually, it still isn't that simple, when writing C# only WinRT apps, you can compile for 'AnyCPU', as soon as you include a C++ portion, you have to build 3 different versions - x86/Win32, x64, and ARM versions, but that's a different problem).
Unfortunately though, like Windows 7/8 Phone, WinRT does NOT support 'normal' Berkeley Socket access, but instead offers its own 'version' of Socket programming, with discrete classes for different socket scenarios, e.g. StreamSocket for a connecting TCP client ( http://msdn.microsoft.com/en-us/library/windows/apps/windows.networking.sockets.streamsocket.aspx#methods ), StreamSocketListener for a bindable TCP server ( http://msdn.microsoft.com/en-us/library/windows/apps/windows.networking.sockets.streamsocketlistener.aspx#methods ), and DatagramSocket / DatagramSocketListener for the UDP versions. Furthermore, only async versions of all the methods are provided.
So it looks like, to get ZeroMQ to compile sucessfully on WinRT, I'm going to have to write a Facade layer that provdes a Berkeley Socket-like C++ interface, and underneath performs the necessary mapping to the version of Socket programming provided by WinRT.
Has anyone else started this journey or written a similar facade? Interested to hear everyone's thoughts, especailly as WinRT looks to quite a 'big thing'!
Though its far from complete or correct and has lots of bugs, but I have started this project here https://winrtsock.codeplex.com. Have not implemented any listen/accept as of yet
You might consider something like ACE. It provides slightly higher-level abstractions over sockets, and supports older windows embedded OSs such as WinCE and the like. It's open source, so you can try it out, hack it up to make it work and contribute back. Alternatively you can contact one of several commercial organizations or people that offer support and contract the work.
I'm trying to set up some integration between Chrome, and various command-line tools and build systems that I have. Almost everything that I want to do within Chrome is supported by the extensions API, so I figured I'd make an extension, set up communication between it and my external tools, and go from there.
Unfortunately, I can't find any sane way to get messages in and out of Chrome. The only thing I could find that would plausibly work at all, would be introduce a local web server as a message broker, having the extension connect to it with WebSockets, and then having the command-line utilities do the same. But that's way too much complexity - it'd basically mean writing a whole IPC framework.
Is there any reasonable way to do this?
There is currently no way to let extensions communicate outside Chrome without XHR/WebSockets/SocketAPI or any traditional methods like Image URLs, JavaScript URLs etc.
If you want make an overkill, you could try creating a NPAPI Plugin that writes protocol messages to disk/file (like how Apache WebServer does), and create another standalone Python script/or any other scripting language that tails that. So your API would basically read that file that the NPAPI Extension Plugin creates.
From what I can recall, ActiveX components are executable files that conform to some form of standard, that can be distributed on the web and run on IE.
Is ActiveX still an 'active' technology? and if not, why not?
EDIT:
I actually write mostly Silverlight and WPF applications at the moment. I am currently working on a presentation regarding plugin technologies, so am more interested in ActiveX from a historical perspective.
I suggest you to develop XBAP Application rather than Activex for the following reasons:
WPF provides more interesting features , and MS do more effort to improve WPF than ActiveX programming.
XBAP application run under a sandbox it's more secure than ActiveX.
Yes, ActiveX is still ‘active’, but is going down because of a number of reasons:
Potential security issues. ActiveX allows execution of native code on the client side and this is the biggest problem. Your personal security depends on control’s vendor.
You can use ActiveX only with Internet Explorer. Last few years IE loses its leadership, so ActiveX becomes less available on client side.
The progress of cross-browser frameworks: Java, Flash, WPF... Five years ago ActiveX was almost the only choice for implementing heavy client side plug-in. Now there is no such performance difference. At least it is not so significant to sacrifice security.
I'd like to know what are the different ways for a browser to interact with external hardware.
Something important : I have control over the machine. That means I can install addons( firefox, chrome ), and run exes on the machine.
I already have a JAVA program that can communicate with the hardware, and I'd like to know how to expose the interface to the browser. So that's one possibility I'm investigating but I'd like to know if there is any other way I can do it.
Thank you
I had a similar problem. The only ways presented were to either use an addon, or write use a tiny C server that uses HTML as it's GUI.
I know you are using Java, and this thread is C++ related, but the basic principles should still work: link here.
You can expose a COM interface from your java application and use silverlight to talk to it. This is significantly simpler if the desktop application is in .NET. Check out: http://www.wintellect.com/CS/blogs/jprosise/archive/2009/12/14/silverlight-4-s-new-com-automation-support.aspx
HTML5 will have a device element that will allow you to connect external devices. Right now, the only choice you have is using plugins to communicate to external hardware.
You can search about NPAPI (a new api called PPAPI is in the making) that will allow you to create a plugin that communicates to native code to do whatever you want.