Many Systems are beginning to use this SASLAuthProtocol (see RFC4422) for authenticating Clients in RESTFUL interactions. Examples are: Couchbase Server 2.0, Memcached e.t.c. I wonder if there is an erlang complete implementation of this authentication protocol. A Java implementation is a good example of what i am looking for. This Python Code seems to be the python implementation of this protocol. Is there an Erlang library i can quickly use to have SASLAuth support in my Application ?
I've not tried this, but it looks like it implements SASL for Erlang:
https://github.com/mikma/esasl
When searching for this kind of thing, take care to avoid the SASL in Erlang, which is System Architecture Support Libraries - "these are not the SASL you're looking for"...
Related
The documentation for Network.WebSockets.runServer says:
Note that this is merely provided for quick-and-dirty standalone applications, for real applications, you should use a real server.
Is this "real server" a reference to something that I'm supposed to know about (if I were more familiar with the Haskell ecosystem), or something that doesn't exist yet?
The actual server can be any TCP application. All you need is support of Berkeley socket from your programming language. This is a nice tutorial from Mozilla on how to write a websocket server.
The real production quality server in Haskell ecosystem is warp. You can use wai-websockets to target it to Warp. In fact wai-websockets uses the package websockets internally.
I would like to work with Cassandra from javascript web app using REST API.
REST should support basic commands working with DB - create table, select/add/update/remove items. Will be perfect to have something similar to odata protocol.
P.S. I'm looking for some library or component. Java is a most preferred.
Staash solution looks perfect for the task - https://github.com/Netflix/staash
You can use DataStax drivers. I used it via Scala but you can use Java, a Session object is a long-lived object and it should not be used in a request/response short-lived fashion but it's up to you.
ref. rules when using datastax drivers
There is no "best" language for REST APIs, it depends on what you're comfortable using. Virtually all languages will be able to do this reasonable well, depending on your skill level.
The obvious choice is probably java, because cassandra's written in java, the java driver from Datastax is well supported, and because it's probably pretty easy to find some spring REST frameworks to do what you want. Second beyond that would be python - again, good driver support and REST frameworks with things like django or flask+potion. Ruby driver isn't bad, lots of ruby REST APIs out there, too.
I want to use a communication mechanism between a server and a linux client, for messaging and discovery. My only requirement is that, the client should be as lightweight as possible. On searching internet, I cam across XMPP and MQTT. But, I am not sure, which of its version is the most lightweight. Can anybody please guide me regarding which is the most lightweight of all. Please let me know, if any other such mechanism exists.
This isn't an easy question, because it's not clear which aspects of "lightweightness" you are looking for. Are you looking for small implementation (in file size), for minimum CPU usage or minimum network requirements.
MQTT and XMPP can both be pretty slim on the client side. Out of the box without any extensions, MQTT most of the time is (much) more lightweight on the wire, it's a binary protocol while XMPP is (without any extensions) XML based. MQTT focuses on efficient Pub/Sub messaging, if you need something fancy on top, you should choose a sophisticated broker (click here for an overview). XMPP has a bit more out of the box. If you don't need things like friendship requests on the protocol level, MQTT is a solid choice.
Again, both protocols have their use cases (which IMHO don't intersect too much). A pretty good overview of MQTT, XMPP, CoAP and HTTP can be found here on slideshare.
I have a multiserver multiclient application and I would like to keep some common data managed by a single daemon (to avoid a nightmare f concurrency), so the servers can just ask it when they need to manipulate the shared data.
I am already using libevent in the servers so I would like to stick to it and use it's RPC framework but I could not find an example of it used in real world.
Google Protobuf provides a RPC framework. And it is also used inside Google for RPC and many other things.
Protobuf is a library for data exchanging.
It handles data serialization, deserialization, compression, and so on.
It is created and opensourced by Google.
However, they didn't opensource the part of RPC implementation.
It only provides a framework.
You can integrate Protobuf with your existing libevent program.
I have personally implemented a RPC with Protobuf and libev(which is a similar project to libevent). And they work fine.
What is difference between rpc frameworks like thrift or gSoap and build-in MS RPC if we talk about security configurations. MSDN describes on http://msdn.microsoft.com/en-us/library/windows/desktop/aa379441(v=vs.85).aspx some aspects, so I can presume that there is support from Microsoft in rpc. Does this mean that if i would like to use different frameworks than MS, I need to take care of security by myself?
This is a very broad question. I'm not quite sure what you really expect, but I'll try to do my best to answer your question.
First, of course you have to take care of the security of whatever you are writing, be it server or client code. Security with regard to RPC services is a wide field, and any sophisticated security feature made available to you by a framework is still just a tool, and still only one part of the overall security concept of your service. To put it in another way: Using SSL will not protect your server from SQL-Injection.
Next, Thift , SOAP and MS-RPC each have different design goals. Thrift is designed with performance and portability in mind. Thrift is more focused on the basic RPC to provide efficiency and portability to any application, for any purpose, in the simplest possible way that works. Of course this approach implies, that there are not much higher-level features, because this is considered being out of the scope of Thrift and left to the user. However, for some of the languages TLS (SSL) transports are available.
In contrast, SOAP is a much richer protocol, based on XML as an machine-readable, standardized and extendable format which can be extended to support higher level features like WS-Security, WS-ReliableMessaging and so on. The downside is, that I have seen many frameworks and development tools which - despite the fact that SOAP has been standardized years ago - are still not able to deal with SOAP in the simpest fashion correctly, let alone supporting WS-Security. Yet, even in spite of this and even in spite of the fact, that SOAP messages tend to produce a lot of traffic and give bad performance, SOAP is still widely used in the industry.
MS-RPC as one of the foundations of DCOM is bound very much to the Windows environment and to Windows development tools. If you can live with that limitation and want to use DCOM, then DCOM offers a very high-level abstraction with good and proven support in today's IDEs.