Non-working demos

[Will Sargent]

So on the website, there's a demo page:

http://opencoweb.org/index.php?option=com_weblinks&view=category&id=4&Itemid=3

And there are two demos listed:

http://vhost1628.developer.ihost.com:8080/cowebx-apps/colist/index.html

http://vhost1628.developer.ihost.com:8080/cowebx-apps/comap/index.html

Both of them give 404 errors.  Has the location changed, or is the site just down?

Will.

[Chris Cotter]

Will,

Try demos.opencoweb.org. This website hosts the latest versions of the demos, using the latest version of the OpenCoweb framework (which was just updated yesterday).

The links you are visiting are obviously broken, and should instead be visited without the "cowebx-apps" in the path:

http://vhost1628.developer.ihost.com:8080/colist/

http://vhost1628.developer.ihost.com:8080/launcher/

Anyway, the demos on that website are actually using an older version of the framework, and are typically used to host development versions of the software anyway. I'll look into updating the links.

If you have any other questions or issues, let us know :)

Chris

[Will Sargent]

On Friday, October 5, 2012 4:15:39 PM UTC-7, Chris Cotter wrote:

Will,

Try demos.opencoweb.org. This website hosts the latest versions of the demos, using the latest version of the OpenCoweb framework (which was just updated yesterday).

The links you are visiting are obviously broken, and should instead be visited without the "cowebx-apps" in the path:

http://vhost1628.developer.ihost.com:8080/colist/

http://vhost1628.developer.ihost.com:8080/launcher/

Anyway, the demos on that website are actually using an older version of the framework, and are typically used to host development versions of the software anyway. I'll look into updating the links.

If you have any other questions or issues, let us know :)

Thanks.  The new documentation at http://opencoweb.org/ocwdocs/intro/arch.html is very clear so far, but I'm still processing the stuff I read yesterday.

I'm still a bit confused as to where the relationship is between client and server.  This is my understanding so far:

The JS client starts up a session to the server using login, and gets for all the inbound events via a join() call back.

User does something.

The JS client sends an event to the OT Engine, defined in coweb-jsoe.

The OT Engine sends a JSON OT event to the server (Python, Java or Node).

The server gets the inbound event, works out what's supposed to happen, then broadcasts that event to any clients with an active session.

The OT Engine on the other clients sort out whether they should apply those events.

The other clients get the applicable events and update themselves to the current state.

Does that sound right?  

I'm still wondering how server side persistence is handled -- I'm also wondering how much common ground OT covers with CQRS, which is a server side event based transformation architecture (explicitly so if you use event sourcing).

Will.

 

[Chris Cotter]

That's nearly the relationship, but I will clarify. The following sequence occurs when a OpenCoweb application is not using the moderator (such as the CoList demo). See also the JS collab API (this is referred to below).

• JS client connects to the server using the unique cowebkey parameter to specify which session to join.
• The JS client asks the server for the full application state (e.g. the entire list in CoList).
• If the client is the first client to join the given session (specified by the cowebkey), the server doesn't send anything back to the client.
• If there are already clients connected to the session, the server asks one of those clients for the full application state. That client sends the full state to the server, which then sends it back to the original joining client. The server doesn't actually store the application state, it must retrieve it from another client. See subscribeStateRequest() and sendStateResponse().
• The original JS client has its subscribeStateResponse() callback called with an argument passed that is the full application state.
• Now, the client performs some operation (e.g. a list insert). This operation is sent to the local OT engine; this is done so that the OT engine knows about local changes to the data structure. The OT engine doesn't return anything useful here.
• The unchanged operation is also sent to the server. The server simply attaches a global total order integer (increasing starting from 0) to the event and sends the event to other participating clients.
• The remote clients receive the remote event and immediately send it to their respective OT engine. Here, the OT engine might transform the event if necessary (e.g. two conflicting delete operations). The remote clients then perform the transform event on their respective local data structures.

The server doesn't store any application state. It's sole purpose is to ferry messages back and forth between clients (because browsers can't make peer to peer connections themselves) and to keep a global total order integer and attach the global total order to each event.

OpenCoweb sessions end when all clients leave a session, and all application state is lost. If another client goes to the application with the same cowebkey, it will see a fresh clean slate.

In the event you (the application developer) want to make an application have persistant state, the moderator will allow state to be persistant. The moderator is a Java object that lives on the server; one moderator exists for each cowebkey, and this moderator object will persist until the server is shutdown. An operation engine lives on the server and will process remote events and send the transformed event to the moderator. The moderator must update its data structures internally. You must write this moderator subclass yourself as each one is specific to a given application.

The way the moderator provides persistence is by being the "updater." In the fourth bullet point above, the server will ask the moderator for full application state instead of some other JS browser client. The moderator fulfills all new client join requests.

See the the CoTree demo. Open a session with some cowebkey (e.g. http://vhost1597.developer.ihost.com:8080/cotree/#/cowebkey/foo) and make some changes. Closing the session and reopening it will have the same persistent state.

I am not familiar with CQRS, but from the googling I did about it, I am not sure how much CQRS and OT have in common. OT lives strictly on the client (the moderator is really a Java client that doesn't generate any events itself), and I'm not sure how the two concepts are common. If you could elaborate more, perhaps I can answer the question better.

Hope this clears up your understanding,

Chris

[Will Sargent]

On Mon, Oct 8, 2012 at 12:27 PM, Chris Cotter <kdsx...@gmail.com> wrote:
> That's nearly the relationship, but I will clarify. The following sequence
> occurs when a OpenCoweb application is not using the moderator (such as the
> CoList demo). See also the JS collab API (this is referred to below).

[useful info snipped]

Thanks, that's a really good overview.

> I am not familiar with CQRS, but from the googling I did about it, I am not
> sure how much CQRS and OT have in common. OT lives strictly on the client
> (the moderator is really a Java client that doesn't generate any events
> itself), and I'm not sure how the two concepts are common. If you could
> elaborate more, perhaps I can answer the question better.

CQRS is a framework that relies lets clients create and send commands
(as encapsulated objects) to the server, and if the command is
successfully processed, the server broadcasts an event to any
listeners indicating what the state change was. It's very useful for
financial systems, where you can use event sourcing -- the existing
state of the system can be derived by running through all the stored
events, and so you can rollback the state of the system to any point
in the past. There's more to it than that, but that's the basics.

Will.

[Chris Cotter]

As far as I know, operational transform is not like CQRS in a huge way: there is no notion of a central server, and thus no central server does any "processing" of events/commands sent between clients. OT is by design decentralized.

The OpenCoweb framework provides OT for event processing and guarantees apps to be synchronized if an application honors all events the OT algorithm returns. Since OCW is meant for web applications, and since browsers are not allowed to communicate in true peer2peer fashion, OCW comes with a central server that ferries messages between clients. As mentioned before, OCW's server also attaches a total order integer to all events; this is a requirement of the specific OT algorithm used by OCW.

As far as I know, there exist alternative OT algorithms that do not need a total order for events. There also exist algorithms with the notion of UNDO. I don't know how these algorithms work, but these might be related to event sourcing. OpenCoweb does not provide any sort of UNDO built into the API itself, although application developers could very well devise their own UNDO framework on top of OCW's API.

Does that more or less satisfy your question about CQRS and OT?

Chris

[Will Sargent]

On Fri, Oct 12, 2012 at 12:08 PM, Chris Cotter <kdsx...@gmail.com> wrote:
> As far as I know, operational transform is not like CQRS in a huge way:
> there is no notion of a central server, and thus no central server does any
> "processing" of events/commands sent between clients. OT is by design
> decentralized.
>
> The OpenCoweb framework provides OT for event processing and guarantees apps
> to be synchronized if an application honors all events the OT algorithm
> returns. Since OCW is meant for web applications, and since browsers are not
> allowed to communicate in true peer2peer fashion, OCW comes with a central
> server that ferries messages between clients. As mentioned before, OCW's
> server also attaches a total order integer to all events; this is a
> requirement of the specific OT algorithm used by OCW.
>
> As far as I know, there exist alternative OT algorithms that do not need a
> total order for events. There also exist algorithms with the notion of UNDO.
> I don't know how these algorithms work, but these might be related to event
> sourcing. OpenCoweb does not provide any sort of UNDO built into the API
> itself, although application developers could very well devise their own
> UNDO framework on top of OCW's API.
>
> Does that more or less satisfy your question about CQRS and OT?

It does indeed, thank you. I'm not particularly worried about undo,
but I do recall Google Wave having an event history and assumed it was
based on OT. Good to know that was something they added on top.

Will.