> I have also been toying with the idea of retrieving AR’s from the server
> and storing them in localstorage as JSON. Then having them process new
> events and storing the events for sync.****

> However this requires domain duplication, a domain on the server for
> hydration.****

> If I go down the client side ES path I should be able to keep one copy of
> the domain on the client, the server is just a pure ES. Merging would be
> done on the client.****

> ** **

> @jon - In your example where are you doing your event sync and merge? Or
> do you not push the events of the client?****

> ** **

> Adam****

> ** **

> *From:* dddcqrs@googlegroups.com [mailto:dddcqrs@googlegroups.com] *On
> Behalf Of *Greg Young
> *Sent:* 14 November 2012 06:57
> *To:* dddcqrs@googlegroups.com
> *Subject:* Re: [DDD/CQRS] Javascript EventStore using LocalStorage?****

> ** **

> Thanks for sharing that! The main point of an indexdb store imho is in
> occasionally connected scenarios eg: wAiting to sync.****

> On Nov 14, 2012 11:59 AM, "Jonathan George" <j...@jonathangeorge.co.uk>
> wrote:****

> I'm doing exactly the same thing at the moment and am storing my events in
> the HTML5 IndexedDB (obviously this restricts the browsers that can be
> used, but I'm ok with that at the moment.) My starting point was a
> Javascript port of Greg's "simplest possible thing" sample - I understand
> that this is not exactly a full blown event store, but I have a fairly
> tight deadline for my first phase which is primarily a proof of concept -
> assuming all goes well I will be revisiting the infrastructure bits in a
> month or so.****

> ** **

> My first pass at porting Greg's C# to JS can be found here -
> https://bitbucket.org/jon_george1/javascriptmvc-cqrs. It's a bit heavier
> than it might have been because I'm using the JavascriptMVC framework (
> http://javascriptmvc.com/) and it comes with a number of health warnings
> - the biggest being that because interactions with IndexedDB are async you
> can run into some major concurrency issues with the code as-is. In the
> codebase for the app I'm working on, I ended up using a plugin (
> http://www.bennadel.com/blog/2326-jQuery-whenSync-Plugin-For-Chaining...)
> to force things into a more synchronous model. There may well be a better
> way of doing this.****

> ** **

> Obviously I can't share my client's codebase with you, but I can pull out
> bits of the code to share if it would be useful for you and I'm more than
> happy to get into more detail on this - it would be good to have someone
> else attempting the same thing as me to bounce ideas off :-)

> Cheers****

> Jon****

> On 13 November 2012 21:26, Adam Mills <a...@chambills.com> wrote:****

> Thanks I'll have a look.
> Not sure what you mean by "store in JSON"? I want persisted storage across
> browser restarts client side, so had planned to store the events in the
> browser LocalStorage, as JSON****

> -----Original Message-----
> From: dddcqrs@googlegroups.com [mailto:dddcqrs@googlegroups.com] On Behalf
> Of Greg Young
> Sent: 13 November 2012 17:24
> To: dddcqrs@googlegroups.com
> Subject: Re: [DDD/CQRS] Javascript EventStore using LocalStorage?

> You can grab some of the code from the Event Store sample chat app
> (github/com/eventstore/eventstore). As a backend it already has js
> libraries
> to handle subscriptions to browser (over atompub and you can host
> projections in the browser if you want).

> As for the localstorage I would just store in json. I can help you with
> this
> if you want as it is something that would be nice to drop into our client
> API as well.

> On Tue, Nov 13, 2012 at 11:20 PM, Adam Mills <a...@chambills.com> wrote:
> > I am looking at doing an occasionally connected app that is entirely
> > hosted in browser, backed by an EventStore that uses LocalStorage
> > (events are also published to a central server, merged and
> > distributed) Has anyone done anything like this?
> > Any code that is shareable? Especially a LocalStorage backed EventStore?

> > Thanks
> > Adam

> --
> Le doute n'est pas une condition agréable, mais la certitude est absurde.*
> ***

> ** **