Date: Wed, 5 Sep 2012 08:27:20 -0700 (PDT)
From: Skipster <dav...@imap.cc>
To: socketstream@googlegroups.com
Message-Id: <60b99319-2066-4dd3-aa99-41c540df1e15@googlegroups.com>
In-Reply-To: <504723EA.1020906@modern-industry.com>
References: <503512B8.8010601@modern-industry.com> <5c961a55-76f0-499f-bfe8-d2647b2962ae@googlegroups.com>
<504723EA.1020906@modern-industry.com>
Subject: Re: Design Patterns for Sleepy Clients
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="----=_Part_32_29356183.1346858840879"
------=_Part_32_29356183.1346858840879
Content-Type: multipart/alternative;
boundary="----=_Part_33_5014488.1346858840879"
------=_Part_33_5014488.1346858840879
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
The problems with using ShareJS with SocketStream are the same for using
ShareJS with Derby. ShareJS is not ready for use, it does too much and
can't be pulled apart (for example, to use SocketStream's transport instead
of its own bindings to SockJS). It also has an open showstopper bug
relating to the JSON OT API being flawed in relation to array operations,
and everything after the array insertion going wrong. Proof beyond all, the
DerbyJS sample apps DON'T WORK, as several posters and myself have
observed. Rearrange a few scrabble letters, and the state tree has already
fallen apart. The ShareJS author, by his own account, has not worked on his
project for a long time, to take it further to completion. He is writing
games instead.
So ShareJS is useful on a conceptual level only. I think its MongoDB and
CouchDB adapters, plus the node JSON diff-patch-merge module, are the
important reference points for doing a mobile synchronization solution for
SocketStream. It's what I'm doing, also with PhoneGap and SocketStream. I'm
using an Ember Data style of API in the client, which is a good place to
produce a JSON diff during a save, because you have the before and after
state of a model there.
David
On Wednesday, September 5, 2012 3:05:36 AM UTC-7, Mike Karliner wrote:
>
> David,
>
> thanks very much for that introduction to state change technologies.
>
> I wonder if you could point out any problems you'd foresee in using
> ShareJS with
> SocketStream?
>
> Mike
>
>
> On 31/08/2012 21:57, Skipster wrote:
>
> This is where durable reliable state change technologies like ShareJS and
> operational transform come in. pub/sub is transient in nature, whereas the
> problem you are actually solving is synchronization, which needs to work if
> the device is waking up after 1 month. In a RequireJS/Derby app, your
> server would be storing a JSON diff of every update to a collection,
> alongside the collection itself. And ShareJS calls that the "ops" or
> JSON-diffs table, whereas your usual collection is called the "snapshot".
> So then what your client should do in response to a pubsub event is trigger
> its "fast sync" process, which is simply doing an RPC to ask the server for
> all the JSON diffs (or "ops" documents) since your last sync, which is a
> watermark in the form of a MongoDB ObjectID of the last ops document.
>
> The great thing about SocketStream is that you can do one of these
> fast-syncs in 2ms. So whenever you get notified of anything, all you really
> need is the collection name. Plus, you put your fast sync logic in
> "ss.server.on(connected)", so that your PhoneGap app just automatically
> starts getting the updates whenever its WAN link comes back online.
>
> It goes without saying that your PhoneGap app should be built against a
> local database, so that it is not just another one of these fake mobile
> "tethered" apps. So then what you're left with is doing the data upload and
> conflict resolution part of your PhoneGap app, which is by nature very
> business domain specific.
>
> You could use a service like Simperium if you wanted to outsource all of
> this, but you give up hosting your own data, and it's also too expensive
> for my taste.
>
> David
>
>
>
> On Wednesday, August 22, 2012 10:11:20 AM UTC-7, Mike Karliner wrote:
>>
>> Hi,
>>
>> For the last few days I've been working away with socketstream
>> pub/sub on a little app that is mainly targeted on mobile devices,
>> and I've come across a design problem that I thought I'd ask
>> the group for advice on.
>>
>> Fundamentally, mobile browsers have a habit of going to sleep
>> when idle for a while, or rather the device does.
>> This means that pub/sub becomes unreliable as events can
>> be lost during sleep periods. Obviously, I can use a couple of
>> different strategies to get round this:
>>
>> 1) Ensure that messages contain all useful state on each transfer,
>> so the next message in the pipe will update the client to current
>> state.
>> 2) Provide an rpc call that returns current state, (although this
>> might be subject to timing holes).
>> 3) Provide a 'catchup' channel that periodically issues the current
>> state.
>>
>> I wonder if anyone has any better patterns?
>> Also, is this going to be a problem with Real Time Models?
>>
>> cheers
>> Mike
>>
>
>
------=_Part_33_5014488.1346858840879
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable
The problems with using ShareJS with SocketStream are the same for using Sh=
areJS with Derby. ShareJS is not ready for use, it does too much and can't =
be pulled apart (for example, to use SocketStream's transport instead of it=
s own bindings to SockJS). It also has an open showstopper bug relating to =
the JSON OT API being flawed in relation to array operations, and everythin=
g after the array insertion going wrong. Proof beyond all, the DerbyJS samp=
le apps DON'T WORK, as several posters and myself have observed. Rearrange =
a few scrabble letters, and the state tree has already fallen apart. The Sh=
areJS author, by his own account, has not worked on his project for a long =
time, to take it further to completion. He is writing games instead.<div><b=
r></div><div>So ShareJS is useful on a conceptual level only. I think its M=
ongoDB and CouchDB adapters, plus the node JSON diff-patch-merge module, ar=
e the important reference points for doing a mobile synchronization solutio=
n for SocketStream. It's what I'm doing, also with PhoneGap and SocketStrea=
m. I'm using an Ember Data style of API in the client, which is a good plac=
e to produce a JSON diff during a save, because you have the before and aft=
er state of a model there.<br><div><br></div><div>David</div><div><br><br>O=
n Wednesday, September 5, 2012 3:05:36 AM UTC-7, Mike Karliner wrote:<block=
quote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-le=
ft: 1px #ccc solid;padding-left: 1ex;">
=20
=20
=20
<div text=3D"#000000" bgcolor=3D"#FFFFFF">
David,<br>
<br>
thanks very much for that introduction to state chan=
ge
technologies.<br>
<br>
I wonder if you could point out any problems you'd f=
oresee in
using ShareJS with<br>
SocketStream?<br>
<br>
Mike<br>
<br>
<br>
<div>On 31/08/2012 21:57, Skipster wrote:<br>
</div>
<blockquote type=3D"cite">This is where durable reliable state change
technologies like ShareJS and operational transform come in.
pub/sub is transient in nature, whereas the problem you are
actually solving is synchronization, which needs to work if the
device is waking up after 1 month. In a RequireJS/Derby app, your
server would be storing a JSON diff of every update to a
collection, alongside the collection itself. And ShareJS calls
that the "ops" or JSON-diffs table, whereas your usual collection
is called the "snapshot". So then what your client should do in
response to a pubsub event is trigger its "fast sync" process,
which is simply doing an RPC to ask the server for all the JSON
diffs (or "ops" documents) since your last sync, which is a
watermark in the form of a MongoDB ObjectID of the last ops
document.
<div><br>
</div>
<div>The great thing about SocketStream is that you can do one of
these fast-syncs in 2ms. So whenever you get notified of
anything, all you really need is the collection name. Plus, you
put your fast sync logic in "ss.server.on(connected)", so that
your PhoneGap app just automatically starts getting the updates
whenever its WAN link comes back online.</div>
<div><br>
</div>
<div>It goes without saying that your PhoneGap app should be built
against a local database, so that it is not just another one of
these fake mobile "tethered" apps. So then what you're left with
is doing the data upload and conflict resolution part of your
PhoneGap app, which is by nature very business domain specific.</di=
v>
<div><br>
</div>
<div>You could use a service like Simperium if you wanted to
outsource all of this, but you give up hosting your own data,
and it's also too expensive for my taste.</div>
<div><br>
</div>
<div>David</div>
<div><br>
<div><br>
<br>
On Wednesday, August 22, 2012 10:11:20 AM UTC-7, Mike Karliner
wrote:
<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0=
.8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,
<br>
<br>
For the last few days I've been working awa=
y with
socketstream
<br>
pub/sub on a little app that is mainly targ=
eted on
mobile devices,
<br>
and I've come across a design problem that =
I thought
I'd ask
<br>
the group for advice on.
<br>
<br>
Fundamentally, mobile browsers have a habit=
of going to
sleep
<br>
when idle for a while, or rather the device=
does.
<br>
This means that pub/sub becomes unreliable =
as events
can
<br>
be lost during sleep periods. Obviously, I =
can use a
couple of
<br>
different strategies to get round this:
<br>
<br>
1) Ensure that messages contain all useful =
state on
each transfer,
<br>
so the next message in the pipe will updat=
e the client
to current
<br>
state.
<br>
2) Provide an rpc call that returns current=
state,
(although this
<br>
might be subject to timing holes).
<br>
3) Provide a 'catchup' channel that periodi=
cally issues
the current <br>
state.
<br>
<br>
I wonder if anyone has any better patterns?
<br>
Also, is this going to be a problem with Re=
al Time
Models?
<br>
<br>
cheers
<br>
Mike
<br>
</blockquote>
</div>
</div>
</blockquote>
<br>
</div>
</blockquote></div></div>
------=_Part_33_5014488.1346858840879--
------=_Part_32_29356183.1346858840879--
Message from discussion Design Patterns for Sleepy Clients
| Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy |
| ©2013 Google |