Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 8 years ago.
Improve this question
I am in the process of building a web based chat app written in Ruby. I would like to provide the ability to also connect to this chat server using an XMPP client. So I am looking for a library that will handle being a real XMPP server which I can tie into with my existing Ruby code (or by using something like Redis in between). However, I am having a hard time finding the server library (though I can find many libraries for acting as a client which consumes or interacts with the server). I'm also not very experienced with XMPP to begin with so I may be asking for the wrong thing. Do you know of an XMPP server library I can use?
XMPP server libraries generally don't make much sense, as XMPP servers (like HTTP servers for example) run as separate standalone long-lived processes. You don't usually embed them into your application.
XMPP is even a step further from HTTP - there are HTTP server libraries that allow you to listen on a port, wait for requests, and send a response. XMPP is completely different in this aspect - XMPP sessions are long-lived, and require constant attention. Using an XMPP server library your application would spend most of the time inside that library - at which point, why isn't it as good as running a separate process?
I know it's a tempting idea, but having developed an XMPP server and thinking about this (people have requested it before you) I just concluded it made very little sense (even if it is technically possible).
Many XMPP servers allow custom plugins for integration with other systems, and there are servers in Ruby if that's a requirement for you (e.g. Vines).
Try XMPP4R
For example - connection and authentication:
require "xmpp4r"
robot = Jabber::Client::new(Jabber::JID::new("sample#xmpp.ru"))
robot.connect
robot.auth("password")
And sending message:
message = Jabber::Message::new("recipient#xmpp.ru", "Hi there!")
message.set_type(:chat)
robot.send message
But the library is somewhat unstable under Windows, but great in Linux.
There is also XMPP server implementation under Ruby using XMPP4R - http://code.google.com/p/xmpp-rserve/
EDIT
Maybe this is what you want. Looks like a library suitable for server usage - https://github.com/sprsquish/blather
Found it on XMPP official page - http://xmpp.org/xmpp-software/libraries/
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
Looking for some general guidance on how to implement a WebSocket client in a way that works on both native Go execution platforms and through GopherJS.
It appears that GopherJS has two WebSocket libraries, one at gopherjs/websocket and one at goxjs/websocket. It seems that goxjs/websocket is "isomorphic", meaning it should work in GopherJS while remaining API-compatible with golang.org/x/net/websocket. That would provide compatibility in both execution environments, which is fine, but I'm not sure if it's the best solution. gopherjs/websocket doesn't appear to work outside of the browser execution environment, so it's a non-starter.
The most recommended WebSocket implementation for native Go apps seems to be gorilla/websocket at the moment. I'd like to use this as it seems to have a good API and it seems rather fully-featured. I can successfully run gopherjs build if I import gorilla/websocket, but I'm concerned that it will fail in the JavaScript environment, or that it will be compiled down into JavaScript that doesn't use the browser's implementation of the WebSocket API.
I'm not seeing much guidance on which library is appropriate for which scenario, so hoping this can help compare and contrast and provide the direction necessary to make a good choice.
I don't have any guidance on what you should do, but can share these facts:
The gorilla/websocket package is an implementation of the Websocket protocol on TCP connections. Because browser applications cannot access TCP connections directly, the gorilla/websocket package will not run in the browser.
There's a difference in the models presented by gorilla/websocket package and the gopherjs/websocket packages. The WebSocket protocol is message-based and the gorilla/websocket package exposes an API around messages. The gopherjs/websocket provides bindings that make the message-based WebSocket protocol look like a stream of bytes. Messages are not exposed in the gopherjs/websocket API.
The x/net/websocket package is all but abandoned. There are long standing issues with protocol compliance that have not been addressed.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I'm working on a Web application that I decoupled it in multiple containerized microservices. I have now around 20 services, but the whole system will definitely need more than 300. Most of the services now and some in the future will not need an entire machine so I'll deploy multiple services on a same host. I'm wondering how others deal with interservice communication. My preferred way was to go with a REST based communication but...
Isn't it too heavy to have multiple web servers running on the same machine? I'm developing in Ruby, but even a lightweight web server like Puma can consume a good amount of memory
I started writing a custom communication channel using UNIX sockets. So, I'd start one web server and my "router" app would communicate with the currently running services on that host through UNIX sockets. But I don't know if it's worth the effort and on top of that, all services have to be written and customized to use this kind of communication. I believe it would be hard to use any framework like Ruby-on-Rails or others, even different languages which is the whole appeal with microservices architecture. I feel like I'm trying to reinventing the wheel.
So, can someone suggest a better approach or vote for one of my current ones?
I appreciate any help,
Thanks,
Looks like you may want to look into docker swarm, they're actively working on these use cases. I wouldn't recommend building your own communication channel, stick with http or maybe use spdy if you're really concerned about performance. Anything you introduce will make using these upcoming solutions more difficult. Also keep in mind you don't need a heavy-duty web server in most cases, you can always introduce a layer above one or more of your services using nginx or haproxy for example.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
What ruby concurrency lib/framework should I use for the development of a web based chat?
I have read about Eventmachine and Celluloid libraries, and about Sinatra::Synchrony, Cramp, Goliath and Gserver concurrency-ready-servers. If I am getting this right, all these libs or servers implement concurrency using two main different approaches: the reactor pattern (mostly all of them), or the use of multithreading (i.e. gserver, ...).
Now if this is all correct, and I hope it is, could someone:
correct me if it is not...
point out other actively developed libraries or frameworks that I've missed ?
The reason I am asking this is that I am trying to build, for learning purposes, a web based chat using ruby on server side. It will interact with client using websockets or Server Side Events, with Jquery or something else.
Also I've read about using ruby with a Xmpp server, or pub/sub messaging system (like Faye). If I put one of these in the dish, am I correct if I say if that it all shrinks down to having to worry only about making requests to those servers in a non-blocking way, rather than having to set-up a complete "non-blocking" ruby chat server ?
I know this is a bit convoluted, but I hope it still make sense..
But in case I am going totally the wrong direction about something, can someone please give me at least a general, vague idea of what I need to understand better ?
Thanks!
Funny you should ask. Peter Cooper from Ruby Weekly mentioned (Issue 116 - October 25, 2012) a talk subtitled "Ruby developers need to stop using EventMachine. It's the wrong direction," which spawned some interesting debate on HN, since many frameworks are built on top of it (Goliath, Cramp, etc.)
The disenchanted flock either to Celluloid (with Sidekiq as its most famous client), to the Node.js platform or to other languages that offer solid concurrency primitives from the get go. Yes, Go, Erlang, Clojure...
Personally, I implemented a realtime web-based chat not long ago using Cramp, Redis Pub/Sub and Websockets, loosely adapted from the following demo code. It worked as advertised, but the traffic it gets doesn't compare to the requirements of some high volume systems elsewhere.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 8 years ago.
Improve this question
I am looking for a Windows graphical utility for performing HTTP operations.
For example, I want to be able to say things like:
POST to http://example.org/test/service
With a POST body: "Data goes here"
Does anyone know a good piece of software for doing this?
I too have been frustrated by the lack of good graphical http clients available for Windows. So over the past couple years I've been developing one myself: I'm Only Resting, "a feature-rich WinForms-based HTTP client." It's open source (Apache License, Version 2.0) with freely available downloads.
It currently has fairly complete coverage of HTTP features except for file uploads, and it provides a very good user interface with great request and response management.
Here's a screenshot:
Update: For people that still come across this, Postman is your best bet now: https://www.getpostman.com/apps
RestClient is my favorite. It's Java based. I think it should meet your needs quite nicely. I particularly like the Auth suppport.
https://github.com/wiztools/rest-client
Have you looked at Fiddler 2 from Microsoft?
http://www.fiddler2.com/fiddler2/
Allows you to generate most types of request for testing, including POST. It also supports capturing HTTP requests made by other applications and reusing those for testing.
You can use Microsoft's WFetch tool also. This is a good tool for all HTTP operations.
You could try Jsonium tool http://jsonium.org- nice free tool specialized on requests with JSON in bodies and responses
http://www.ieinspector.com/httpanalyzer/
http://www.microsoft.com/downloads/details.aspx?FamilyID=B134A806-D50E-4664-8348-DA5C17129210&displaylang=en
https://addons.mozilla.org/en-US/firefox/addon/9780/
http://soft-net.net/SendHTTPTool.aspx
https://addons.mozilla.org/en-US/firefox/addon/966/
Honestly, for simplistic stuff like that I typically whip up a quick HTML form in a local file and load that up in a browser.
I like rest-client a lot for the purposes you described. It's a Java application to test REST-based web services.
If anybody is still interest Eclipse Labs Rest Client tool is an excellent choice. I'm trying it in Windows in an EXE version and works smoothly.
I've worked also with Rest Client previously and its great too.
https://play.google.com/store/apps/details?id=com.snmba.restclient
works from Android Tablets & Phones. Flexible enough to try various combinations.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 8 years ago.
Improve this question
Relating to this question, Upload files directly to Amazon S3 from ASP.NET application, is there any way to do this and have a progress bar?
---- EDIT ----
Two days later and still no luck with a direct way. Found one thing that looks promising but not free: http://www.flajaxian.com/
Uses flash to upload directly to S3 with a progress bar.
I'm looking for a solution as well. Maybe this will be of some help,
From AWS Dev Commnity
But in many languages (PHP, Java), for
big files, you have to use streams
through which the language environment
will take chunks of your big file one
after the other (in order to fill up
central memory with huge amount of
data for the http POST of S3 needed
for the upload.
The nice thing about stream is that
they have a callback called whenever
the next chunk is read for to further
PUT (in the https sense) data to S3.
You can use this callback to compute
and display the progress on the client
UI.
See the doc of libcurl to see in
details how all this works.
Update: It looks like there are two straightforward options.
Flash, via the FileReference class
With a Java applet
I personally hate using 3rd party extensions (Flash, Java) to make an app function, but I haven't found another way.
html5 javascript can allow you to do it, if you don't mind lack of browser support (Firefox and Chrome only as of this post_
Example here: https://developer.mozilla.org/en/Using_files_from_web_applications
This isn't specific to AWS, but may help you get closer.
Another approach is to use something like Uber Uploader (http://uber-uploader.sourceforge.net/) which is a perl / php hybrid solution with a progress bar. You would simply upload the files to your server and then have your server FTP them in the background to the final destination. It is an extra step but it gives you some time to do any processing / encoding / etc. that you may need to do before sending to S3.