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.
Related
I'm developing client-server application on haxe. I want client side to be compiled to javascript from haxe, but there is a big chance, that other languages will be also needed. I cannot find universal way of doing it. Though, I can make it with websockets, when it comes to jabascript, and on haxe Sockets, in every other language.
So question is: is there a way to make a client-server application on haxe, without branching code for different platforms?
What you are looking for is Haxe Remoting, which is part of the Standard Library
Haxe remoting is a way to communicate between different platforms. With Haxe remoting, applications can transmit data transparently, send data and call methods between server and client side.
relevant sources:
http://haxe.org/manual/std-remoting.html
http://api.haxe.org/haxe/remoting/
As side note, if you are looking into creating a actual website with client/server in one project you might want to look into http://www.ufront.net
I have some experience with socket.io and the main reason I was using it previously is to have a fallback in older browsers. Currently I have to develop an app with websockets, which has specific browser requirements. When I checked the browser matrix for websocket support, I see that all the browsers I need support websockets.
So right now I have a dilemma. Should I stick with socket.io or implement it with pure websockets? When I checked websocket API, I see that it is super simple. I made a small research into this problem and also this question sounds similar, it's main component is compatibility with old browsers (which I do not care).
So is there any advantage of socket.io if compatibility is not an issue?
Yes, there are. I can see 3 advantages of using Socket.IO even when developing for new browsers:
First of all, there are firewalls (see comments below), antiviruses, and proxies that block WebSockets. In this case XHR fallback would be extremely useful to ensure your service's availability for all users.
Second, Socket.IO supports autoreconnection, so you don't have to worry about temporary network failures.
And third, there are rooms and namespaces support, which makes writing real-time applications much easier and enjoyable.
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.
I need to create a simple Chat system like facebook chat and a twitter-like app.
What is the best concurrent program languages in this case ?
Erlang, Haskell, Scala or anything else ?
Thanks ^_^
Chat system like facebook chat
Facebook chat is written in Erlang, http://www.facebook.com/note.php?note_id=14218138919
and a twitter-like app
What aspect? Message delivery? The web frontend? It's all message routing ultimately. Haskell's been used recently for a couple of real time production trading systems, using heavy multicore concurrency. http://www.starling-software.com/misc/icfp-2009-cjs.pdf
More relevant: what's the scale: how many users do you expect to serve concurrently?
Erlang is my choice of drug for something like that. But I would also check out Node.js if you feel more comfortable in JavaScript.
Complete chat application source code using Scala/Lift.
8 minutes and 20 seconds real-time, unedited, webcast writing a chat app from scratch using Scala/Lift.
This is actually a relatively easy problem to solve that can be done by any language with decent threading support including (eg Java, C# and others). The model is fairly simple:
Each client connects to a Web server with an AJAX request that is configured on the server not to timeout;
If it does timeout for any reason the client is configured to issue another AJAX request;
The server endpoint for that AJSX call does a thread wait operation on some monitor waiting for updates;
When the user sends a chat it is sent to the server and any relevant monitors are signaled;
Any threads listening to that monitor are woken up, retrieve any messages waiting for them and return that as the AJAX result to the client;
The client renders those messages and then issues another AJAX request to listen to for messages.
This is the basic framework but isn't the end of the story. Any scalable chat system will support either internal or external federation (meaning the clients can connect to more than one server) but unless you're Google, Facebook or Twitter you're unlikely to have this problem.
If you do you need some kind of message queue/bus for inter-server communication.
This is something you need a heavy duty multithreaded language like Erlang for but it, Haskell and others are of course capable of doing it.
F# for future.
Client/Server chat F#
Concurrent Programming - A Primer
Also take a look at Twisted(Python).
I'd recommend taking a look at Akka (www.akkasource.org)
It's a Scala Actor framework with ALOT of plumbing for making scalable backend applications.
Out of the box it supports:
Actor Supervision
Remote actors
Cluster Membership
Comet over JAX-RS (Project Atmosphere)
HTTP Auth for your services
Distributed storage engine support (Cassandra, MongoDB)
+ a whole lot more
I would go for erlang, it's efficiency in comet-enabled apps is largely proven.
Go with a framework such as nitrogen, where you can start comet requests just as easily as Jquery does ajax.
If it's actually going to be a simple application (and not under very high load), then the answer is to use whichever language you already know that has decent threading. Erlang, Scala, Clojure, Haskell, F#, etc., all do a perfectly good job at things like this--but so do Java and C#. You'll be fine if you pick whichever of these you know and/or like.
If you're using this as an excuse to learn a new generally useful language, I'd pick Scala as a nice blend of highly performant (which Erlang is not in general, though it is fantastic with efficient concurrency), highly functional (which Java and C# are not), highly deployable (due to running on the JVM), and reasonably familiar (assuming you know C-ish languages).
If you're using this as an excuse to practice fault-tolerant concurrency, use Erlang. That's what it was designed for and it does it extremely well.
I am planning to build a web chat on my site. I know two way of doing this: one is using XMPP web client (through flash, long TCP connection), and the other is facebook way， long-polling.
But facebook is going to update their chat to support Jabber (XMPP), so can some one tell what way is better? (including upgrading to XMPP)
I've had pretty good results with long polling in my applications, but the bigger question is whether you're going to face the C10K problem. If so, structuring your code to deal with that kind of intense workload will likely dominate all other design considerations, at least in the short term. :-)
Other than server load, the primary consideration for which strategy to use will be client environment compatibility -- to be able to work from behind draconian firewalls that only allow HTTP or in browser environments that prohibit any plugins, long polling is the only way to survive, but it has more overhead than the simple TCP connection approach.
They have different pros and cons, for eg: TCP requires a plugin (at least until HTML5 web sockets get widely supported), Long Polling is less performant, etc. I'm not an specialist on this differences, that's why I'll recomend you to avoid making this choice, avoid developing and tuning that each approach involves, avoid the future changes in available technologies (ie. as HTML5 arrival), using a library that abstracts the transport method used, and chooses the best approach based on client capabilities:
http://socket.io/
this wonderful library makes creating realtime apps amazingly simple! and there are various server-side implementations: Python (Tornado), Java, Google GO, Rack (Ruby), besides the mainstream implementation in Node.js (server-side JavaScript)