REBIN: Use any CLI app/script as a web service(intridea.com)
intridea.com
REBIN: Use any CLI app/script as a web service
http://www.intridea.com/blog/2013/2/27/rebin
5 comments
The thing is, you can still do all this in Apache now. CGI still exists (in fact, it's the default way Perl's ran). So I'm really struggling to work out why I'd install their tool over Apache.
And I don't mean this negatively, I really do want to know what separates this product from existing webservers runing CGI, but there's no useful information on their website what-so-ever.
If any of the Rebin devs are reading this, are you able to elaborate on this tool a little more?
And I don't mean this negatively, I really do want to know what separates this product from existing webservers runing CGI, but there's no useful information on their website what-so-ever.
If any of the Rebin devs are reading this, are you able to elaborate on this tool a little more?
Hi, one of the developers here. Not all servers run CGI. Sure, while there are wrappers that can do it, for example for nginx, it isn't pretty. The purpose for REBIN is a clear and concise serving of executables without the overhead of say Apache. I think the readme is rather verbose... Call me surprised :)
To be brutally honest, the readme didn't really sell the product. But then I guess that's not the point of the readme. However none of your other documentation (blog posts, Rebin product page, etc) explained what sets this product apart either.
I think I get it's point now - though I can't pretend to be sure of that. I can see that you're trying to do something a little different from CGI (which, incidentally is available for node.js as well), I'm just not entirely sure how different you two are. I guess the proof of that may just be in using it :)
Either way, it's good to see it up on github and I'm sure plenty people will be grateful for your work.
I think I get it's point now - though I can't pretend to be sure of that. I can see that you're trying to do something a little different from CGI (which, incidentally is available for node.js as well), I'm just not entirely sure how different you two are. I guess the proof of that may just be in using it :)
Either way, it's good to see it up on github and I'm sure plenty people will be grateful for your work.
Thanks for this! We have some plans that may indeed differentiate further from CGI.
If this was a small tool with no dependencies, then it would be a clear winner over a heavy-weight install of apache, just to serve it. But, as is, I don't see the real benefit over apache, unless you already have redis and node running.
Hi, it's still super small relatively speaking. As far as Node and Redis, those are both pretty common these days.
I agree, it could use some practical examples. The announcement sounds very grandiloquent but it doesn't say much. The readme in the source is not much more explicit:
"You have already or have created a CLI based application or script. It takes input, it produces output. Now, how do you expose your work to the web so you can utilize via a web service. REBIN takes care of that!"
Great!
"You have already or have created a CLI based application or script. It takes input, it produces output. Now, how do you expose your work to the web so you can utilize via a web service. REBIN takes care of that!"
Great!
-> grandiloquent? (it's designed just to be simple) like the message :)
Yep, instances are asynchronous and can handle long running processes. As for cg-bin circa 1996, I appreciate your long memory! But nothing was RESTful back then. ;-)
I'm having trouble understanding how a wrapper for an arbitrary executable can be called "RESTful". Are there resources? Are there long-lived URIs?
In the end, doesn't the implementation of the executable partly determine whether it is really RESTful?
In the end, doesn't the implementation of the executable partly determine whether it is really RESTful?
Good question!
Certainly long-lived URI's. As for resources, I suppose conceptually there is. However you are correct that the given executable would determine a level for resources. So I guess the answer is YES. Support for RESTul is RESTful. Or not, depending upon your executable.
Certainly long-lived URI's. As for resources, I suppose conceptually there is. However you are correct that the given executable would determine a level for resources. So I guess the answer is YES. Support for RESTul is RESTful. Or not, depending upon your executable.
This looks very useful. However, looking at it on github, I see there is no Windows version (yet). I am interested in this so I can access and run Windows-only processes from a sane Linux environment within my server cluster. Is there any interest or on going effort to extend Rebin to Windows?
It's open source, so have your way with it.
Cool!
Anyone know if it can asynchronously handle long-running processes?