[aerogear-dev] Sync Day 3 Sync takes Manhattan

Thu Jan 30 12:02:00 EST 2014

On Thu, Jan 30, 2014 at 5:13 PM, Summers Pittman <supittma at redhat.com>wrote:

>  On 01/30/2014 11:03 AM, Matthias Wessendorf wrote:
>
>
>
>
> On Thu, Jan 30, 2014 at 4:23 PM, Summers Pittman <supittma at redhat.com>wrote:
>
>> I rolled up the feedback to the email I sent yesterday.
>>
>> One quick note, this is not a 0.1.0 plan nor a 1.0.0 plan.  It is
>> probably closer to a 1.5 or 2.0 plan in terms of scope.
>
>
>  ahm... thinking about 2.0.0 before we have a 1.0.0 ? Not sure I
> understand that
>
> The point I was trying to make is that I'm not expecting everything on
> here to get done quickly from top to bottom and slap 1.0 on it sometime in
> May.
>

Oh, ok - yeah, I totally agree that we should _not_ say: 1.0 is in May and
it contains all the bits from your M1 -> M8;

> Also that I am expecting to have several releases made during the
> production of points on this list.
>

yep!

>
>
>>  I tried to
>> order things and break out big "chunks" which will need to be done and
>> the approximate order they should be done in while also drawing a line
>> around what features we have.  This is why I have not placed ANY
>> versions YET.  By the end of today/tomorrow morning I hope that we will
>> be in a good place to do that.
>>
>
>
>
>
>>
>> Big changes from yesterday, User mgmt moved to M4.  M6 (Sync Listener
>> Upgrading)was merged into M3(Push Listeners) so that we can have
>> optional push sooner.
>>
>> # 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.
>>
>
>  +1
>
>
>>
>>
>> M2 - Sync Listener w/ Polling based sync listener, conflict 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
>>
>
>
>  +1
>
>
>>
>>
>> M3 - Push based Sync Listener, Sync Listener Strategy Management
>>    * The client and server will negotiate when it is appropriate to
>> switch between polling, push, and realtime sync strategies.
>>    * We will build on our previous Listener work from M2 to include a
>> Push listener that the server can speak to.
>>    * We will support ways of automagically managing sync listeners based
>> on the availability of Push.
>>
>
>
>  overall, yes - the nasty details can be discussed at a later point, hence
> +1
>
>
>>
>> M4 - Server user management, Network Management, Server side session
>> management
>>    * 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.
>>   * The server should have a basic authentication and authorization plan
>> for controlling how data is synced
>>
>
>
>  this assume we do have a server w/ pluggable adapters, no ?
> E.g. JPA/JavaEE/Hibernate adapters verus YetAnotherDatabaseThingy adapter
>
> Yeah, that is something we are lacking in this list is what the abilities
> of our server "are".
>

that was my thought as well

>
> For the most part I assumed that each step a server technology or spec was
> built up and kept up.
>

I think a 'real' server (w/ adapters) might be needed at some point :-)

>
>
>
>
>>
>> M5 - "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.
>>    * Previous Sync listeners may have to be upgraded to include "upload"
>> abilities.
>>    * We will also include the ability to switch between Realtime sync
>> listeners, polling listeners, and push listeners
>>    * The server will need to support this as well.
>>
>
>  Didn't M3 already include 'realtime' ?
>
> For me real time means there is a persistent connection.
>

same here - but that's listed (real-time) in M3 as well, right ?

If the client is offline the message fails and there is an error.  Also
> realtime means that changes made to the client's data are automatically
> uploaded and propagated.
>
+1

>   M3 was only concerning itself with detecting changes of remote data and
> notifying the user and possible doing some merging if there wasn't a
> conflict.
>

Ah!! ok, did not get that from reading the list

>
> Also in this step is the ability for the server to send the changes
> themselves instead of sending a notification that something changed.
>

agreed

>
> I think of push technologies like a message queue.  Deliveries are
> eventually made and trusted to get made at some random point in the future.
>

well, I have some thoughts on that, when we get there :)

>
>
>
>
>>
>> M6 - 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
>>
>> M8 - Party
>>    * We have a sync party.
>>
>
>  what about M7?  :)
>
>
> M7 was scared of 8 so it is hiding.
>

I hope it was not: buy all the booze for M8 :-)

>
>
>
>
>> _______________________________________________
>> 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
>
>
> _______________________________________________
> aerogear-dev mailing listaerogear-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
> _______________________________________________
> 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/b2c0befe/attachment.html 