[aerogear-dev] Sync Day 2: All our cars are frozen in ice

[Matthias Wessendorf]

On Wed, Jan 29, 2014 at 4:41 PM, Summers Pittman <supittma at redhat.com>wrote:

> I'm going to take some time to roll up yesterday's Sync Thread so we can
> stop chasing down individual ideas.
>
> Also I am going to propose a potential milestone conga line.  I think
> one of the things that keeps happening in these discussions is everyone
> has an idea of what sync is but we don't really know what order things
> should be done or released in.
>
> If everyone likes this I'll slice things into JIRA epics.
>
> # M1 - Basic revision Control, Data Model, Change Management, Server <->
> Client Contract
>
>   * We seem to be in agreement on a basic set of metadata to be kept for
> each object.  [objectId, revision, object].
>   * We should have a basic server definition which supports CRUD and
> keeps our revision numbers in check.  This may not be a server product
> but just a spec that can be implemented by anything at this point.
>   * We should have basic client code which keeps up with revisions, can
> check the server for new revisions, and alert the user if there is a
> sync conflict.
>

what about looking at local changes ? Is that implied here?


>
>
> M2 - Sync Listener w/ Polling based sync listener, conflict management,
> Serve user management
>   * We define on the client how callbacks will work for alerts when
> remote data changes
>   * We implement a listener which polls a data source and delivers
> changes to the user.
>   * We define how conflicts are managed
>   * The server should have a basic authentication and authorization plan
> for controlling how data is synced
>

Not sure, but: could/should a  user get the chance to kinda control that
'change' (e.g. veto) ?


>
> M3 - Push based Sync Listener, Network Management, Serverside session
> management
>   * We will build on our previous Listener work from M2 to include a
> Push listener that the server can speak to.
>   * We will define in the client how network state and sync state
> interact.  IE how to handle errors in fetching new data when the
> Listener is alerted. (Exponential back off, retry, etc)
>   * The server will need to have some mechanism for managing user
> "sessions".  This is what users are actively being synced.
>

I still think this is optional :-)

I think generally it's nice to have feature that the "sync-server" can send
'update requests'
to the unifiedpush server; However IMO the clients should still mark this
as optional (again
a user (on iOS/FFOS) can decide she is not interested in push notification;
Than all the offerings
from M3 would just not work


>
> M4 - "Real Time" Sync Listener.  Bidirectional automatic sync
>   * Instead of using push, Realtime Sync uses something like web
> sockects. to automatically sync local and remote data.
>

Should be the default when an app is active and open (putting platform
limits aside)


>   * Previous Sync listeners may have to be upgraded to include "upload"
> abilities.
>   * The server will need to support this as well.
>

This step might allow us (*later*) to plug in some sort of OT (Operational
Transform) implementation



>
> M5 - Conflict resolution, Error detection and support
>   * Provide a more comprehensive strategy for managing conflicts.
>   * Provide some automated conflict resolvers
>   * The server could get a larger set of conflict and errors messages
>

+1


>
> M6 - Sync connection Upgrading
>   * The client and server will negotiate when it is appropriate to
> switch between polling, push, and realtime sync strategies.
>

yeah, sounds good


>
> M7 - Party
>   * We have a sync party.
>

Jägermeister and fine brews from Russian River -> yay!


> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>



-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140130/68e82390/attachment-0001.html