We have an application which consumes a large amount of data. Currently a desktop app, but we would like to deliver it via the browser.
It doesn't make sense to me to create a web app where we need to transfer a ll the data used for the visualizations.
We're looking at RDP and some products out there that provide RDP access via a fully javascript client. They seem to work well with our app, but I've been thinking about what it would take to move off Windows.
Switching the front end so that it could run under Linux would not be trivial, but not impossible, so the main stumbling block would be delivery.
I was wondering if there are any X11 javascript servers out there, but have not found any leads.
Use xpra's builtin html5 client, it supports any application you can run on an X11 desktop.
You can use an HTML5 VNC viewer like https://github.com/kanaka/noVNC coupled with a VNC server like RealVNC
AFAIK, recent GTK has been ported to HTML5+Javascript in Gtk Broadway
And you could make your application a web application, for instance by using Wt, or by making it an HTTP server thru specialized HTTP server libraries like libonion, libmicrohttpd etc.
By using AJAX techniques (e.g. thru jquery) your application won't transmit all the display data to the browser at once (but only incrementally and only the actually shown data).
You might also consider fastcgi as a way to connect your application to some web server.
I know two, both at very infancy:
https://github.com/GothAck/javascript-x-server
and
https://github.com/ttaubert/x-server-js
Both need simple tcp-to-websockets proxy in front, but all X11 logic happen inside web page and all x11 objects exist and interact within browser (so it's not just remote framebuffer but real server)
You can ever run full Linux distribution in Web Browser, but that's require to run x86/ARM emulator and GNU/Linux inside it. It provides X server with possible web connection too.
For very simple applications you can use libgreattao toolkit and tao-network-client to connect to it. I'm the author of both project. The API isn't yet frozen, but it rather behaves stable. You can read about it here:
https://nintyfan.wordpress.com/2015/04/30/server-buildin-into-libgreattao-and-tao-network-client/
It can provide some problems with applications with a lot of data, because all elements must be send to client, when it were created, but instead we don't send full graphics(only icons is send) and user interface could be changed quickly. It also don't support mouse enter/leave/move events.
I must tell: do not download tarbar, but download version from svn.
Sounds like the easiest approach for you is to get xrdp, which is an RDP-server for X. Then you would use your RDP client to connect to it. I think Nomachine NX supports html directly now, but I'm not sure. There was talk of an html X2go-client, but I don't know anything about that either.
Related
I am building an application that will allow user to open a word document through a web page. This web application will open the word document using the local word instance on the machine.
I have two working solutions.
Using ActiveX (Only on IE)
Since the application is intranet application, I am using PsTools in the web service to remotely open word instance on remote machines.
The second architecture is what I am following right now. It is based on a Web Service which receives machines name through Javascript/jquery call. Later in the web method I am using PsTools to remotely execute MS Word instance on remote machine.
Both the architecture works, but both of them have limitations. With ActiveX I can use it on IE and it also requires changes in network policy to allow ActiveX. With PsTools, it is working great but I can't get the path of Word.Exe and I can only assume that it would always be at \\machinename\C$\Program Files(x86)\.....
We might make this application public as well and in that case our solution with PsTools will not work anymore.
I was just wondering if there is any other more suitable/cross browser way to open local word instance through web application ?
The document has to be modified on a remote location, one option would be to let the user download the document, then modify it and upload it to the server, this is out of question since we are replacing a thick client and wants to keep the user experience same
I am building an application that will allow user to open a word
document through a web page.
If it is an Intranet scenario, then you could use application protocol with Office URI schemes for links to the documents which will then open in the locally installed client.
The Office URI schema is like this:
<scheme-name>:<command-name>"|"<command-argument-descriptor> "|"<command-argument>
For Word specifically, an example would be:
<a href='ms-word:ofe|u|https://example.com/example.docx'>Edit</a>
Where, ms-word: is the scheme, ofe command stands for open-for-edit, the u is the command-descriptor to use the URI that follows, and finally the URI to the document itself. There are other commands like ofv (open-for-view), and nft (new-from-template), and also other command-descriptors like s for save.
Here is the complete reference: https://msdn.microsoft.com/en-us/library/office/dn906146.aspx
The protocols are registered with Windows when the Office client is installed.
You could enable WebDAV easily on your IIS server. The WebDAV client is built-in with Windows at the client-side.
You can also use components like FFWinPlugin Plug-in which is part of the SharePoint Foundation, or OpenDocuments Control which is an ActiveX control installed along with the Office client.
We might make this application public as well
I would discourage you from doing that, unless your company owns or deals-with services like OneDrive or Office.com. This can quickly get tricky as mentioned in the other answer. Moreover, enforcing a proprietary client on general public is not a good idea anyway. Further, even Microsoft's own solutions do not work reliably across browsers and work best with IE only (even Edge has problems with this), which would be forcing a specific browser to general public. Not a good idea.
However, if you really need to, then it would be better if you could use some of the solutions already built around WebDAV. Alfresco ECM (enterprise content management) is one example of public offering which uses WebDAV similar to your use-case.
There is another one by IT Hit and a live demo is here: http://www.ajaxbrowser.com. They also have a basic tutorial on how to setup your own WebDAV server on the same lines as your use-case. You will need to find their documentation.
When you say: "We might make this application public as well", what kind of scale are you talking about? Just a couple of folks from the a team, or as a real web application that needs to deal with edit conflicts, transactions, locking, performance, etc.? Even the intranet solution you mentioned will likely become a headache as soon as 2-3 people start to edit the same document.
For this type of document sharing, you basically have two options:
Significant investment in a rich web UI that behaves similarly to MS Word, with back-end services that will store the info in a scalable data store and provide simultaneous edits and document downloads, or
Integrating with a third party vendor API or white-label provider that offers similar capabilities for a fee. E.g. Box.com APIs, HyperOffice, FirePad, etc.
This would be a super-simple problem to solve if you can convert the document in question to a type of form. There are probably a hundred different services that offer embedded forms functionality with excellent reporting and database management. If a document in Word format is needed, then your app would just convert the stored data to a .doc/.docx document for users to download at will.
Whatever direction you go with, try to get out of the PsTools-based current setup. It's like a rinkydink house of cards and as #Matt-Burland mentions, likely to cause a security disaster pretty soon.
I want to connect a bunch of weather sensors to a Raspberry PI. Writing the daemon that reads the sensors and writes the data to a database will be the easy part since I'm a systems programmer. I also want a simple cross platform UI for this device so I'd like to set my Raspberry Pi up as a WIFI hotspot that people can connect to and then just entering a URL like 'weather.local' into a browser which would take them to a web page where the weather sensor data is continually updated. I.e. I want the sensor daemon to 'push' updates to the web page.
The problem is that I'm no web developer. The solutions I can think of off the top of my head are:
Flash, which is out because I want this to work on mobile browsers.
Using Java script and hanging HTTP requests to a web service.
HTML5 socket.io which is presumably the same as WebSocket.
If I go with option (2) even if it's a kind of polling, I'll have to incorporate some form of HTTP server into my sensor daemon and I have a fair idea of how to code that. My question, however, regards the HTML5 socket IO. Can I use this to connect directly to a TCP/IP binary socket or do I need a server side WebSocket library? Also how widely is HTML5 socket.io/WebSocket implemented on mobile browsers?
WebSocket always begins with an upgrade handshake over HTTP, so you do need to have basic HTTP capability. It's simple enough that you can hand-code it.
WebSockets is basically supported by all modern browsers. It is not used that widely because it's a pain to set up on traditional HTTP servers and messes up with many proxies, but that's not a problem for you. As long as the client is a recent version of anything, it'll work.
A note about option 2: browsers have a native implementation of it — that means you don't need so much JavaScript on the client. You just create the EventSource object and listen to its events.
I have been working with node.js for a while, now when I'm looking deeper into it, for a chat aplication instead of sending message as client - server - client, there must be some possible ways for direct client to client message sending?
Browsers tend to communicate with servers via HTTP. Some implement other protocols, like websockets & SPDY, but again, these are mostly client-server protocols.
Some plug-ins (like Flash & Java) can open ports and communicate client-client. (AFAIK, haven't actually used them.)
Chrome is the only browser I'm aware of that can (soon) open TCP and UDP sockets from Javascript and do direct client-client communication. At the moment normal web apps can't do this, your app needs to be run as a "Chrome Packaged App", with a special manifest file.
Here are the docs, a blog post describing the feature and a browserify module that can behave like the net node.js module in the browser.
EDIT: This should probably not be tagged as [node.js] since you're trying to run in browsers (not in your node vm), this is a Javascript / Browser question.
This is maybe out of date question, but take a look on PeerJS.
It requires server only as a connection manager (broker). But all communication is done between clients directly.
This does not have anything with server. If you need something like that and if clients are flash you can use RTMFP . For JS i google this library which is js bridge for RTMFP, I dont know how it works. At the end you can write you own library to chat beetween clients but this is much harder(IP addresses are behind NAT, etc...)
I think answer for your question is here
PS Also exist open-source in-browser server which written using JS, but I didn't google it quickly. If you find it, please notify me.
If you just don't want to write your own server you can use:
https://httprelay.io
Use AJAX calls to communicate between peers.
I have an external application that is automating some tasks on a website. My goal is to implement a system which allows for the program and Chrome to synchronize cookies. While it is possible to query Chrome's cookie DB to read cookies, it is not possible to update the DB since Chrome maintains an I/O lock on the file, thus preventing easy synchronization.
The next logical step to me was to attempt to create an extension which will update cookies as necessary (through Chrome's cookie API). However, after about two days of research I have been unable to find an effective means to communicating cookie data between the browser and my application (which is written in Python.)
Sockets are out because it's for desktop based applications only. Websockets are out because as far as I can see it's impossible to setup a Websocket server using the HTML5 API (which is what I need since the browser needs to be the server and the program would be a connecting client). I'm really not sure what I am left with at this point. Is there something really obvious that I'm missing here? Any help is appreciated, cheers.
This feels like a very weird way to do whatever you're trying to do. Why are you doing this again?
Anyway, the most obvious solution is this:
You obviously have to secure communication between the app/plugin and the server. Again, this feels like a very weird way of doing stuff. But the solution will work. In this case both the app and the plugin are WS clients and your server is the arbiter.
Introduction: I want to develop the chat client that user can chat on the browser and I use the protocol call xmpp. Because of HTML5 web socket not yet available I try flash xmlsocket instead.
Problem: I cannot connect to the server via browser. I'm not sure why, but I think that it is the problem of the server configuration.
Question: Which is the best jabber server suitable for this job?
Most probably this is a permission issue. Either that or you've just configured the wrong host/port to connect to. Flash is not allowed to connect to other hosts than the one it was gotten from itself. You have to explicitely allow flash connections on the receiving side of the request (so on the chat server that you are connecting to). Google for crossdomain.xml to get more info.
ejabberd sounds like a suitable option for you. ejabberd is xmpp server written in erlang and is used quite widely. Many of the well known web based im services like www.meebo.com etc are known to be running on ejabberd. It allows you to install other transports which would let you enable talking to users of other protocol like yahoo, msn, icq etc.
You can also have a look at the xiff action script library by ignite realtime. It is an xmpp client library in action script. If you use this library you would just need to implement the ui components.
Hum... flash is ok, but you'd be better of using something like BOSH, which is basically an HTTP layer over XMPP.
Ejabberd would be a good server, as it supports BOSH, I don't know about OpenFire or Tigase (but I'd say they do). Other servers should be looked at carefully because they don't seem to have a "dynamic" community.
You will need a lot of Javascript, and for that, I can recommend StropheJS, which is probably the very best library out there today.
We have created a MUC (Multi-user chat room) client called Aristochat that works in the browser recently at Superfeedr. You can find the code on Github and an example here.