what is the VAS exactly? is it specialy for communication? - gamekit

can I say that some value added services in a mobile game or application are VAS?
I have a challenge with myself because i heard that VAS is specialy for the communication services.

VAS is commonly used in the telecom industry, it's true.
But it is a vague term, that can be used by anyone - see the Wikipedia page. . There's no legal meaning to these words.
I think you can use it if you have added value to something that is generally accepted as an industry standard, or a necessary service.

Related

Connection between programs over the network

I want to dive into the whole diversity of tools which provide connection between programs over the network.
To clarify the question, I divide it on subquestions:
Why some groups of programs (or specific tools/frameworks/approaches with programming languages where this frameworks can be used) were popular in each period of time? (I expect description of problems which were solved, description of tools, why those tools are considered as best solution to those problems at that time, why some tools lost popularity)
What is the entire history of software communication over the network? (tools/approaches popularity precisely to decades)
What are the modern solutions to this problem?
I can distinguish only two significant approaches.
RPC, RMI and their implementations (I saw this, but it is about concrete problem and specific tools to solve this problem, I want to see the place of this problem in the whole picture of interconnection programs over the network. I heard about implementations: ONC RPC, XML-RPC, CORBA, DCOM, gRPC, but which are active now? which are reasonable to use? which are preferable and why? I want answers not to be opinion based, so I accept answers like "technology A better than technology B for problem X because ..." only if there is reliable research/statistics or facts). I heard that RPC and RMI were popular 10 years ago. Are they still?
Web services: REST, SOAP.
Am I miss something? Maybe there are some technologies which solve problem completely new way? Maybe there are technologies which can be treated as replacement to RPC(RMI) and Web Services? Can we replace RPC(RMI) by REST for any task? Can we replace RPC(RMI) by REST only for modern tasks? Should I separate technologies not as RPC and Web Services, but in some other manner?
As a partial answer, I can give you my feedback on the use of RabbitMQ.
As explain here, it provides a lot of different ways to use it :
RPC by implementing a "callback" queue
One to one, one to many routing strategy to propagate your events through your whole infrastructure and target the right destination.
It comes with the ability to persist messages to avoid loosing data when a crash appears but also with some plugins to increase possibilities (e.g x-delayed plugin)
This technologie written in Erlang is powerful and is a must try in term of communication between programs.
To your question „Am I missing something“: yes.
Very popular communication patterns are the so-called Event-Driven or Message-Driven protocols. This type of protocols are often used in distributed systems such web applications, microservices and IoT-Environments. The communication is complete asynchronously and allows building scalable and loosely coupled systems.
There are many different frameworks and methods for Event-Driven systems like WebSockets, WebHooks, Pub-Sub and Messaging-Librarys like AcitveMQ, OpenMQ, RabbitMQ, ZeroMQ and MQTT.
Hope this info helps for your research.

How do I implement activesync protocol in iphone app?

How do I implement activesync protocol in iphone app?
Any advice, any docs and tutorials are well come.
I have read the Exchange ActiveSync and iOS 4 Devices from apple.
Is there any real docs for this?
Despite having asked a question in the comment, you might be looking for the Microsoft documentation of the Exchange Server Protocols.
If you're thinking of implementing your own client though, I would strongly advise you to pause and consider whether it's really worth it. As someone who's worked on a server-side implementation of these protocols, I can tell you they can get pretty complicated - and the documentation doesn't always give you enough information. (In some areas it's flat out wrong, too.)
It is hard, but not impossible to write an app which communicates via exchange active sync. The link to the Exchange Server Protocols in Jons answer contains a document named MS-ASWBXML. You have to write an encoder for wbxml on your own and the document describes clearly the needs. Additionaly I recommend strongly this document: http://www.w3.org/TR/wbxml/
If the low level is working, you have to implement the EAS-protocol on top ob wbxml, which is not trivial, because of bugs in the documentation, different behaviour of different protocol versions. It will be a lot of trial an error to examine, why the exchange server does not understand your requests ;-)
Using Apple's built in support just means using Apple's APIs for writing to the Address Book and Calendar Store on the phone. Your app isn't supposed to know anything about the way that data is synchronised: it just happens in the background.
If you want direct control over the synchronisation process, then Apple's APIs cannot help you. Jon Skeet's answer contains a link to Microsoft's protocol documentation, but as he mentioned you'll be setting yourself up for a world of pain.
EAS is really meant for device makers to implement and not normal application development. You should look over the ActiveSync Protocol documentation and look into licensing the protocol (yeah its a pay-for license) and then ask yourself if its worth all the trouble to write all the business logic, ecoding logic, intensive testing and the licensing. An alternative is to use Exchange Web Services (EWS), which might be a much better fit - more rhobust in many areas and no licensing needed.
You should also look at this: http://blogs.msdn.com/b/webdav_101/archive/2011/09/29/new-to-exchange-activesync-development.aspx

How to implement group chatting/message-board mobile app?

I am trying to write a iPhone group chatting/message-board app which will have a backend component. I expect users to register with our system and start posting messages on chatrooms/message-boards. These message-boards can have more than 2 individuals, must support real time notifications and should be accessible from any other clients (like web) as well.
I stumbled upon http://code.google.com/p/xmppframework/ . I realize that XMPP is a very attractive proposition for our needs but I am seriously worried about the infrastructure complexities and scale issues. Besides, XMPP has way too much to offer for my needs. Looks like, XMPP might be the only choice for my pleasure in pain, but I wanted to see what you experts have to say on this.
Any thoughts?
Thanks,
My advice is: whichever protocol you're choosing, do not try to invent your own protocol. Go for XMPP or if you can find an alternative which you find more compelling, use that. Especially if there's already a nice framework for you to use. Why ? Because a single developer new to a field is seldom smarter than a bunch of people with experience ;-) Make use of other peoples' experience by using an established protocol, and make use of existing frameworks to avoid coding mistakes and investing a lot of time to solve a problem yet again that was already solved.
That being said, XMPP is widely deployed and thus would make for a good choice if you later plan to write additional clients for other platforms or want to have third-party clients connect to your server.

Point to Point environment ->Restful

After I read that sentence:
SOAP was designed for a distributed computing environment whereas
REST was designed for a point to point environment.
I searched about DCE and point to point environment. I learned about DCE but I found nothing about point to point environment. So what is it?
I believe "SOAP was designed for a distributed computing environment" boils down to meaning SOAP is an RPC mechanism. From what I understand, "point to point environment" is really just another way of saying that the protocol implementing the style is client/server and only supports unicast addressing.
It's a meaningless contrast, really. And, if my understanding is correct, the "point to point environment" bit is rubbish - HTTP might not support anything other than unicast addressing of resources, but that doesn't mean that any other protocol supporting the RESTful style, hypothetical or otherwise, couldn't have an addressing mechanism for resources that mapped onto potentially multiple resources.
Of course, I'm only making an educated guess.
REST - Used on the web for a larger scale internet applications and websites(twitter.com) Point To Point = internet.
SOAP - Used in Busienss Systems, Commonly Used With Existing XML Schema from third parties.

iPhone Networking

If I have make an application, how would I make it interact with a database on a server of mine? I'm kind of lost, and don't know where to start.
Vague question yields a vague answer.
It entirely depends on what kind of interaction you need. Lots of constant queries? Few and far between? Client side cache? Real time updates? All of these questions will impact the answer.
The easiest way is to go with an AJAX style HTTP based client/server type of interaction. Sticking a database behind a web server has been done about a bazillion times and, thus, you'll find lots and lots of examples and, even, solutions with a few google searches.
You don't really need to use JavaScript (the J in AJAX). Instead, send over an HTTP request that encapsulates your query and have the server respond with an XML document containing the answer.
If that won't work for you -- too much overhead, need to relay binary information (for which XML sucks), etc.. -- then you'll wan to go with more direct access to the database. That is harder and can range from porting a client library to the iPhone to creating your own wire protocol.
A significantly harder problem and you'll have to deal with networking issues -- firewalls, NAT, proxies, etc... -- that are generally already solved with HTTP.
Stick with HTTP until you prove that it won't work. Much simpler.
Search for "http request" in the iPhone docs. HTTP client APIs are included.
You might try Apple's "Getting Started with Networking & Internet" or "Introduction to the URL Loading System", in addition to the Networking section of the iPhone Application Programming Guide. There are also several sample applications that handle networking of various types within the ADC's iPhone section.
Additionally, there are a number of open source iPhone applications out there that handle networking, including my own.
I had a similar question regarding a rails app - the answers there may help you.
What is the best approach for building an iphone client for a rails app?
But the answer really depends on your knowledge of iphone programming and server side programming, plus how your database is set up at the moment - but most likely you're going to need to write some kind of webservice / REST API that allows a remote client to do things with your database.
There are many frameworks available for that on the server side - if you're starting from scratch, ruby on rails may be a good choice.
On the iphone side, you'll probably want to start by reading up on NSURLConnection, and various request/response formats that you can use with it. I've found exchanging plists between the phone and server to be a pretty easy approach.