Win 1000$ by developing your own real time collaboration Action Script 3 application with the XTWIP service!

Join the XTWIP contest now, come up with an ingenious application, implement it and send it to us before the 7th of May 2010. Create a developer account to take advantage of the full features of our service. See what real time collaboration is all about !

Submitted applications must contain the executable form (SWF) as well as the source code. We will publish all submitted application on our website. The winner will be established by universal vote.

Do you know creative Action Script 3 Developers ?

WIN 500$ by referring the winning developer to the XTWIP competition !

This is your chance to show how many creative Action Script developers you have in your contact list. Just make sure to join the XTWIP competition as a referrer and that all developers who join the competition by your recommendation also confirm your email address.

After all the participants will have submitted their application, we will publish the applications on the XTWIP website. The winner will be established by universal vote.

You should follow us on Twitter @xtwip for news.

Whether you are a developer or a referrer, be sure to check out the terms and conditions for the XTWIP contest before you join.

All participants (developers and referrers) must enrol on the XTWIP before the 6th of May 2010.

Developers must submit their final Flash/Flex applications before 7th of May, 2010, 23:55 CET

All information provided by participants shall be true, accurate and up-to-date at all times, including, but not limited to, information concerning intellectual property ownership and rights thereto.

Terms and Conditions for Developers

1. Developers can win 1000$ (tax-free)  by creating and submitting a Flash/Flex application that is real time collaborative and uses the XTWIP framework and service in order to achieve real time collaboration features.
2. By real time collaboration features one must understand that several users cansimultaneously edit the same content within the same instance of the application. For example, if the application draws&designs wireframes for user-interfaces, real time collaboration would allow multiple users to edit the same wireframe (drag buttons, change labels, create, delete, group elements and so on) at the same time, all of them seeing the changes being made almost instantaneously.
3. By submitting, all developers must agree to publish source code and executable form (swf) applications under the Apache 2.0 license. XTWIP will publish all the submitted applications (both source code and executable form), mentioning the author’s name.
4. The developer can choose to keep his anonymity. In that situation, only the application will be published.
5. After the submission period deadline (7th of May), all the applications will be published on www.xtwip.com
6. The winning application will be decided by open vote, in the 7 days following the submission deadline (8 – 15 May). The official winner will be announced on the 16th of May.
7. The announced Winning Developer will receive a prize of 1000$, tax-free on a credit/debit card or bank account of their choice.
8. Developers who were referred to by a third party must confirm the identity of that third party by its email address upon the developer’s registration. A developer can only mention one referrer. The referrer confirmed by the winning developer also receives a 500$ prize.
9. The Developer can include any other technology, framework or source code available to him, as long there are no licensing conflict with the submitted application or that the developer has explicit permission for use. All liability for potential conflict belongs to the Developer.
10. Developers agree to design the user experience and interface for their application only in English.
11. In order for the prize to be given by XTWIP to the Winning Developer, a minimum of 10 (ten)  eligible applications must be submitted before the specified the deadline. In case fewer applications are submitted, XTWIP retains the right not to give the 1000$ prize to the Winning Developer.
12. Teams of developers may apply to work together on the same application. However, we only deal with one contact person and there is only one prize

Terms and Conditions for Referrers

1. Referrers can win 500$ USD (tax free) by recommending the XTWIP Contest to developers who enrol in the contest and send an eligible real time collaboration application before the deadline (7th of May). The only referrer who wins is the one who recommended the only developer who wins.
2. Referrers must provide the name (first, last) and the email address of the developers they have encouraged to join the XTWIP contest.
3. There is no limit on how many referrals one referrer can make.
4. Upon subscription, the Developer must confirm the email address of his referrer in the enrolment form. A referral without the Developer’s confirmation will not be acknowledge.
5. A Developer may only confirm one referrer (by one valid email address).
6. If several referrals occur for the same developer, we will only consider the one the developer confirms.
7. If a developer confirms a referrer that has not listed the developer, the referral is considered valid.
8. If a developer confirms a referrer that has not joined the contest, the referral is considered invalid.

If you have questions or suggestion, please use our feedback form and we’ll get back to you.

Think of the workspace as some sort of real time interactive, collaborative document.

workspace = real time XML document

While running a collaborative instance of your application, all changes are tracked, sent to all online participants and saved on the XTWIP. However, in this post we’re going to show you how to create, delete and access a workspace.

Creating a workspace

As a third party application developer, all you need to do is post a request to our front end server, authenticating yourself by sending the devKey provided to you. The server will respond with the workspaceID assigned to that workspace. You will need to store this ID, since you will later need it to refer the workspace. For more information on how to post a create workspace request, go through the XTWIP JSON-RPC API Reference [pdf].

Here’s what happens when you make the request

1. The user  hits a “New” button and the server-side for your application receives a request.
2. Your server then forwards the request to the XTWIP server, providing the devKey as an authentication mechanism. Optionally, it can also provide a name for the workspace or an initial content of the workspace XML (by default, the name is set to “Workspace” and the XML content is set to be empty).
3. The XTWIP front end performs a number of tasks before  stepping further:
   • • Checks the availability of your devKey
     • Checks if you have the right to create additional workspaces (if the creation limits per developer has not been exceeded)
     • Are you a paying customer ? Should any additional quality of service conditions be met for this request ?
     • It balances the request on the least occupied backend server, depending on your developer subscription type.
     • Finally, it forwards the request to the backend server that best fits several criteria (load, quality of service).
4. The backend server actually creates the workspace and it confirms the operations as successful. In case the operation fails, the request will be sent again to another available backend server.
5. The front end server marks the operation as successful, stores the workspace ID in the database together with the server onto which it is hosted. It returns the workspace ID to the developer server.
6. The developer server should also store the workspace ID, for any further reference (access request, deletion etc). It also notifies the end-user of the successful operation.

As a general fact, the business logic inside the XTWIP infrastructure is transparent to you. In order to manage collaboration instances, you only need to post the JSON-RPC requests and interpret the results.

Accesing a workspace

After you’ve created the workspace, your main concern will be how to access it: how to make your application aware of the collaboration instance and make sure all changes are delivered on that instance.

The XTWIP SDK for Flash/Flex automatically looks for the authentication information it needs to connect to the workspace in the flashvars of the embed code of your application. In order to get that authentication information however, you need to follow the steps described below:

1. The user decides to open an existing workspace, so the browser sends a request to the developer server.
2. Your developer server makes any additional verification (“does this user have rights to the workspace requested?” sort of thing). If everything checks out, the request for access is forwarded to the XTWIP front-end, together with the devKey associated to the application. Optionally, the email and the name of the user may be provided, so each user can have a unique identity in the collaboration environment.
3. The XTWIP front-end authenticates that the developer identified by devKey indeed has the right to access the workspace. It also finds the back-end server that currently stores the workspace. After that, a request for a temporary token is sent to the back-end server.
4. The back-end server randomly generates a temporary username & temporary password and then sends them to the front-end.
5. The front-end forwards them to the developer server, together with the IP and the port of the back-end server that is hosting the collaboration session.
6. The developer server pastes the temporary username and temporary password into the embed code for the collaborative application.
7. The application runs, the XTWIP Flash/Flex SDK loads the authentication data from the embed code (flashvars) and it connects to the back-end server, providing the credentials for authentication. The application instance has now joined collaboration on the workspace and may send/receive data, changes, chat messages, presence, ownership and so on.

This combination of devKey and temporary credentials bares several guarantees of security and flexibility:

• Each developer can only access those workspaces he/she created.
• Developers can define their own access control policies for their users (since this logic is to be implemented in the developer server, not in the XTWIP infrastructure)
• Users cannot access workspaces without a confirmation of access rights from the application developer.
• Users do not have access to devKey and do not have access to directly creating, deleting or accessing workspaces (without going through the application developer)
• Temporary credentials expire minutes after the user has left the collaboration session. In order to reconnect, the user must obtain a new set of temporary credentials.

Deleting a workspace

The workflow for deleting a workspace is almost the same as for creating one, the only exception being you need to provide the ID of the workspace you wish to delete.

We hope this post provided an overview on how you, as a developer, can manage the collaboration instances hosted on the XTWIP infrastructure. For a more detailed understanding of creating, deleting, accessing and retrieving workspaces, go through the XTWIP JSON-RPC API Reference [pdf].

When developing XTWIP, we had in mind harnessing the power of the real time web in order to make people focus, work together and get things done while keeping up to date with relevant developments from co-workers. Our service helps developers bring their application users together in producing information, rapidly reviewing it and delivering it on time. XTWIP is about shifting real time from quantity to quality.

Most real time services on the web have an outward perspective, inviting people to share and re-share information that has already been produced (blog/magazine articles, pictures, artwork, witty quotes and so on). XTWIP challenges developers to rethink the possibilities of their applications so they can engage teams of users to:

• be more creative & inspired
• brainstorm while actually working
• distribute tasks naturally and efficiently
• deliver faster, with less effort
• turn negative stress (deadlines) into positive stress (reciprocal engagement)

And have you ever noticed how annoying is to have work and communication as two separate processes ? You sit at your desk trying to focus on your tasks. All of a sudden, 5 emails rush in a completely mess up your thought patterns, even if those emails directly concern what you are working on. What if you could receive the feedback and the help you need directly in the design you’re creating ? Or in the document you’re writing ? Or in the workflow you’re so meticulously laying out ?

Wouldn’t it be better if the people who nag you about “how you should change the color scheme on that web page concept” could actually change the color scheme themselves, side-by-side with you ?

How about not spending 10 minutes on the phone with a customer who’s trying to explain how to drag 2 buttons around around to the upper-left side corner ? How about if he could do it himself while you watch and fine-tune? That would be a very empowering feeling to the customer and it would be a great time (and stress) saver for you.

So what if you’re an architect or interior designer ? Maybe your clients are as busy and you are and they can’t afford dropping by your office in the middle of the day. They could just drop a link in the browser and they could drag the virtual furniture around, while you discretely assist them in making the right choices, step by step. This would save a lot of frustration on both sides, don’t you think ?

Or how about shopping together with your online friends ? Maybe it’s for a group gift you want to buy or even just for the fun of it.

Wait wait… I think I have a better one. How about you design your own Nikes together with your friends ?

Our vision is about merging work and communication into one single process. About actually producing information in a social, fun and interactive way.

XTWIP is the backend technology that makes this work. We have taken the first step to making the real time web more than a context(less?) conversation. Now we need you – developers, designers and visionaries – to meet us half way.

Or – as Elvis so eloquently put it – “A little less conversation, a little more action please“

Do you have a great idea about a real time collaboration application ? Drop in a comment, send us your feedback give or twitter us about it.

The object based approach follows these 4 simple rules:

• The data model of the collaborative application can be represented as an XML. Of course, the application can pull data from Twitter, Flickr or Facebook, but by data model we mean the data the application stores.

• Whenever the application changes something, it just notifies the XTWIP client-side SDK that “something has changed”. The SDK automatically detects what has changed and send the difference over to the XTWIP server and to the other application instances.

• In order to better avoid conflicts, the XML may have atomic tags or non-atomic tags. An atomic tag has an unique ID attribute and it may contain either atomic or non-atomic tags. A non-atomic tag does not have a unique ID and it may only contain other non-atomic tags. The XTWIP SDK provides the unique IDs and it guarantees they are unique across all application instances. You can think of atomic tag as components which the developer considers important enough to separate and non-atomic tags as properties of those components. See the example below to get a better idea.

<!– The document is an important tag, so it gets a unique ID –>

<document id=”7″>

<!– The same goes for the button –>

<button id=”9″>

<!– The attributes of the button however, are not that important from a collaborative stand-point  –>

<label text=”Collaborative Button” color=”6600FF”>

<background src=”xtwip_logo.jpg>

<background color=”222222″>

<link url=”http://www.xtwip.com”>

</button>
[...]

</document>

• When two application instances (actually, two users) change the same atomic tag at the same time, the last change has priority over the first. Of course, a merging of the content will be attempted – failing that, the last change will remain. The distinction between atomic and non-atomic tags comes in very handy here, because it tells the merging algorithm how it should try to match tags.

This (apparently) simple protocol provides application developers with a simple gateway to collaboration. No longer do they have to write server-side code or write their own custom code for diffing and merging differences. The XTWIP SDK together with the XTWIP Collaboration Service provide that for just a few lines of code. All developers need to do is read the tutorial, drop a few lines of code into their application and they can redeploy their application as a collaboration experience.

Let’s look at the advantages:

1. Very easy to deploy. There is not specific server-side logic and developers can just embed their application and the XTWIP SDK takes care of the rest (connecting to server, handshaking, getting data, posting differences and so on)
2. Very easy to implement. All you need to add to your application is: listening for when outside changes appear (so you know when to redraw), notifying the SDK of when something has changed, serializing your data model (XML serialization is already built in the SDK) and adding a connect statement on application load. That’s it !
3. Fast execution, low CPU cost. Unlike Operational Transforms methods, object based diffing is significantly faster.
4. Guaranteed consistency. This means that all application instances will rapidly converge to the same instance of the data model, no matter how many changes are being performed.

There are only two disadvantages:

Number one. If two users happen to modify the exact same atomic object at the same time (within 300 ms of each other, on average), the XTWIP SDK will automatically merge the two changes. When merging fails, the last change performed will implicitly have priority.  Merging means a further analysis of what has changed (attributes, child tags) and putting it all together. Merging usually fails when the two users change exactly the same attributes and no automatic conclusion can be drawn as to who’s right.

In our experience, however, this type of fine-grained micro-conflict between versions is very rare. When it does happen, the users notice it right away. They tend to immediately react and choose a final state for the change they wanted.

Number two. Whole pieces of the data model are serialized and send across the network, so if your application deals a lot with raster image editing, object-based collaboration is not the best idea (at least, not by itself).

If you want to try this type of real time collaboration with your own application, create a Developer Account on XTWIP and there you’ll find everything you need:

• A short tutorial on how to get started
• The client side SDK
• A full documentation on the protocol
• A full description with examples on how to manage (create, delete, request access) to multiple collaborative instances (workspaces)

We’re on a trip to learning right now. We learn from you, the everyday users. But this is a new approach for us, IT specialists and developers.

Product Development
Since our startup began, we faced a lot of technical challenges and mostly put our efforts on creating a prototype for you guys. We failed with the private alpha release and we continued to improve it until we changed 70% of it. Now we have the SDK ready, the free developer accounts in place, documentations and a demo of a collaborative application, developed on ActionScript, our primary developing language. But it’s not enough.

Customer Development

Now, we’re onto a new trip. We plan to learn. In an disorganized way, investing 70% of our time networking and searching for people that have the need that we’re solving. It’s like most of today’s entrepreneurs called it “the exit from the comfort zone“.

The belief that people don’t like it when you offer to much is a fact. We tried, again and again and again, to contact people in order to attract them in using our technology. We didn’t take into account, that perhaps it’s better to offer little of what’s important to them, not much of unimportant stuff.

If you think we  consider ourselves damned by now, think again. We had a vision and we had to concrete it. But now, it’s time for others to speak and to visualize their needs implemented into our service. We’re looking forward to that.

That’s all for now.

For this example, we’ll consider a simple application in you can draw boxes, and you have only 4 options:

• makeNewBox(centerX,centerY)
• deleteOldBox(boxID)
• translateBox(boxID, X, Y)
• rotateBox(boxID, alpha)

It means that instances of the application transmit across the network only  the actions taken in order to get from the old state to the new state. This is extremely useful if you have data models that take up a lot of space (like 3D polygon models), but changes made to them can be described using very little space.

So let’s say you have application A and application B, working on the same instance containing square1 and square2. Let’s say square1 is already rotated by 30 degrees, and instance A rotates it with another 15 degrees (to a total of 45 degrees). Instead of sending out rotateBox(square1, 45), it sends out rotateBox(square1,15). The great advantage of this approach if two rotations occur in (near) real time, they can get composed over the network. So if, at the same time, application B, applies and additional rotation of 10 degrees, the end result (in both instance A and B).

The order on the generated events will be the order they reach the XTWIP server. It this case, it may seem that the order of the events is irrelevant, but most actions (operations) are not commutative – that is changing the order of two actions changes the end result they yield.

The advantages of this approach:

• Events end up having one single order in all application instances (everyone sees the same thing)
• Concurrent changes (same time, same object) are composed
• Small traffic across the network

The disadvantages are however more subtle and only through implementing experience did we learn about them:

• Composing concurrent changes isn’t always the best thing to do. Coming back to the previous example, if user A rotates the square by 15 degree and user B rotates it by 10 degrees, the end result will be a total rotation of 25 degrees. This is a mix of what both users wanted. But in fact it isn’t what either of them wanted.

• Requires server-side logic – in this model, the XTWIP server has to be aware of what rotateBox means. So the logic for actually performing the rotation has to be on the server. The downside is that with every application you deploy, the logic for all its operations has to be deployed on the XTWIP server as well. So this means more work for developers who use our server for deploying their apps and more work for us (because we would have to enforce advanced security restrictions on application logic). More work = bad news

These significant disadvantages of the event-driven model lead us to the decision that we needed an alternative way of offering real time collaboration, with less debugging, less risks and less work. This is how we came up with the object-driven collaboration model …

* Keep following the Types of Collaboration series to get a true insight on how XTWIP provides real time collaboration for your Web & Rich Internet Applications.

However, we soon realized that from a technical stand-point there are three fundamental ways of implementing real time collaboration. To the end-user this probably has no impact whatsoever. But for the developer who makes his/her application collaborative, it is of great importance to choose the best mix of these models:

• Event based collaboration – actions are sent over the network. The XTWIP server has the logic to execute application specific operations on its own data model.

• Object based – XML-formatted object structures are sent over the network, depending on the part that changes. The XTWIP server requires no logic to execute application specific operations.

• Data based collaboration – actions are sent over the network. The XTWIP server has no logic to execute application specific operations and it periodically polls client-sided applications for the latest data model. The server stores the data model, serves it to new clients, but it doesn’t understand the data, nor does it have the logic to change it.

• Operational Transforms (OT) based collaboration (this is the stuff Google Wave uses). The collaboration server has logic to execute general purpose editing operations (insert, delete, skip) and also the logic to “merge” these operations together. For instance, if two users send concurrent actions (almost) simultaneously, those specific actions are modified by OT when they reach their destination so that they make sense in the new context. The server stores and periodically updates the data model. However, OT is very CPU intensive and the results it produces are usually more than what most application developers need.

In the following posts, we’ll explain the differences between these types of collaboration and how you should pick the one the suits best your use case/business case.

We got great feedback – and by great I mean useful, concrete stuff we can actually get started on. More details to come when we get back to Bucharest.

What was your Seedcamp experience like ?

Later edit: Check out the XTWIP presentation on SlideShare

If you have exactly 1 min, give this survey a try. When we have reached 100 responses, we will publish the results.

Enjoy the weekend!