<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, May 6, 2014 at 3:26 PM, Burr Sutter <span dir="ltr"><<a href="mailto:bsutter@redhat.com" target="_blank">bsutter@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Number 2<br>
<br>
Broadcast push for new contact/customer to all users/salespeople<br>
Cordova-ized for iOS and Android<br>
Native Objective-C & Android Java impls as well, is that about right?<br></blockquote><div>yes </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
On May 6, 2014, at 9:07 AM, Bruno Oliveira <<a href="mailto:bruno@abstractj.org">bruno@abstractj.org</a>> wrote:<br>
<br>
> 2 sounds reasonable, go for it<br>
><br>
> On 2014-05-06, Matthias Wessendorf wrote:<br>
>> yes, sounds like 2) is the way to go<br>
>><br>
>><br>
>> On Tue, May 6, 2014 at 9:10 AM, Sebastien Blanc <<a href="mailto:scm.blanc@gmail.com">scm.blanc@gmail.com</a>> wrote:<br>
>><br>
>>> Anyone else ?<br>
>>> If we all agree I can adapt the temporary backend I deployed including<br>
>>> this new behaviour.<br>
>>><br>
>>> Sebi<br>
>>><br>
>>><br>
>>><br>
>>> On Mon, May 5, 2014 at 9:34 AM, Christos Vasilakis <<a href="mailto:cvasilak@gmail.com">cvasilak@gmail.com</a>>wrote:<br>
>>><br>
>>>> Hi,<br>
>>>><br>
>>>> answers inline<br>
>>>><br>
>>>> On May 2, 2014, at 11:37 PM, Jay Balunas <<a href="mailto:jbalunas@redhat.com">jbalunas@redhat.com</a>> wrote:<br>
>>>><br>
>>>>> I wanted to chime in here on additional/related items around the<br>
>>>> contacts use-case and specifically around how to integrate push. Some of<br>
>>>> these have already been discussed so just getting in one place for my own<br>
>>>> sanity :-)<br>
>>>>><br>
>>>>> 1) I agree that users and "contacts" are separate things. I think it<br>
>>>> is best to think about them as was mentioned below - users (employees) and<br>
>>>> contacts (customers, leads, etc...). This is easier to grok imo and could<br>
>>>> be helped by some simple wording in the UI.<br>
>>>><br>
>>>> +1<br>
>>>><br>
>>>><br>
>>>>> Cons:<br>
>>>>> ** We then need a way to add "users" - otherwise we won't be sending<br>
>>>> many push messages. Maybe users could be automatically created when an app<br>
>>>> first accesses the backend?<br>
>>>><br>
>>>> already the backend provides endpoints for creation of “users”, as well<br>
>>>> as a list of default users initialised once the app is first loaded. By<br>
>>>> default when a new user is created the security role assigned to it doesn’t<br>
>>>> allow the creation of new contacts, you get back an “Unauthorised” error.<br>
>>>> It doesn’t effect push per se, since an “admin” user can create a contact<br>
>>>> and the notification can be send to all other users that are logged in, but<br>
>>>> we should document this behaviour.<br>
>>>><br>
>>>>><br>
>>>>> 2) Simplifying the push use-case: If we change the use-case from<br>
>>>> saying hi to specific contacts to notifying all users when a new contact<br>
>>>> was created it could simplify not only the UI, but the server side<br>
>>>> processing for the push. We could reserve the more specific push usage to<br>
>>>> the console, and/or AeroDoc.<br>
>>>>><br>
>>>>> If we go with 2) we might be able to avoid the issues with 1)<br>
>>>> altogether because a broadcast would send to every app that has registered.<br>
>>>>><br>
>>>>> Wdyt?<br>
>>>><br>
>>>> I am +1 on this behaviour. IMHO its more clear for the end-user and the<br>
>>>> actual notification is used to “alert” for a change on the server part that<br>
>>>> the app can decided to respond (e.g. fetch the new contact list).<br>
>>>><br>
>>>> Thanks,<br>
>>>> Christos<br>
>>>><br>
>>>><br>
>>>>><br>
>>>>><br>
>>>>> On May 1, 2014, at 10:46 AM, Burr Sutter <<a href="mailto:bsutter@redhat.com">bsutter@redhat.com</a>> wrote:<br>
>>>>><br>
>>>>>> Joshua owns the backend, let's see if he has a thought on this item.<br>
>>>>>><br>
>>>>>> On May 1, 2014, at 7:25 AM, Christos Vasilakis <<a href="mailto:cvasilak@gmail.com">cvasilak@gmail.com</a>><br>
>>>> wrote:<br>
>>>>>><br>
>>>>>>> Hi everyone,<br>
>>>>>>><br>
>>>>>>> have started working on the iOS native client of the contacts quick<br>
>>>> start app. Based on edewit branch[1] (which creates a contact on signup of<br>
>>>> a user) have created an initial version of the iOS client and you can find<br>
>>>> it here [2], together with a screencast showcasing the app in action [3].<br>
>>>>>>><br>
>>>>>>> Some comments observed during writing of the application which would<br>
>>>> like your feedback:<br>
>>>>>>><br>
>>>>>>> a) for PUT, DELETE operations noticed that the jax-rs backend<br>
>>>> expects the id of the Contact to be present in the body of the request. Not<br>
>>>> sure why this was chosen instead of @Path(“id”) resulting against<br>
>>>> /contacts/{id} ?<br>
>>>>>>><br>
>>>>>>> b) currently roles are used to distinguish between who is able to<br>
>>>> create/update/delete contact. When a user signs up (and contact is<br>
>>>> created), by default the user is _not_ able to apply any CRUD operations<br>
>>>> apart from viewing (any operation results in unauthorised error). If we<br>
>>>> agree on this behaviour, would like to know how can I determine the role of<br>
>>>> the user (in order to update the UI accordingly, eg. disabling add,edit UI<br>
>>>> elements). Looking at the json response upon login of the user, couldn’t<br>
>>>> determine a “key” that specifies the role (apart from an “admin” key which<br>
>>>> stayed the same regardless of the type of the user).<br>
>>>>>>><br>
>>>>>>><br>
>>>>>>> Thanks,<br>
>>>>>>> Christos<br>
>>>>>>><br>
>>>>>>> [1]<br>
>>>> <a href="https://github.com/edewit/jboss-wfk-quickstarts/tree/push_and_secured" target="_blank">https://github.com/edewit/jboss-wfk-quickstarts/tree/push_and_secured</a><br>
>>>>>>> [2] <a href="https://github.com/cvasilak/aerogear-push-quickstarts/tree/ios" target="_blank">https://github.com/cvasilak/aerogear-push-quickstarts/tree/ios</a><br>
>>>>>>> [3] <a href="https://vimeo.com/93471554" target="_blank">https://vimeo.com/93471554</a><br>
>>>>>>><br>
>>>>>>><br>
>>>>>>><br>
>>>>>>> On Apr 23, 2014, at 5:43 PM, Erik Jan de Wit <<a href="mailto:edewit@redhat.com">edewit@redhat.com</a>><br>
>>>> wrote:<br>
>>>>>>><br>
>>>>>>>> Right, that makes sense, so let’s not join them. The alternate thing<br>
>>>> to do is to create a contact on sign up, because if you want to receive<br>
>>>> push notifications at least you should be in the list of contacts. We will<br>
>>>> still need to change the sign up page a little as we need a phone number<br>
>>>> and a birth date as well in order to create a contact.<br>
>>>>>>>><br>
>>>>>>>> On 23 Apr,2014, at 16:26 , Burr Sutter <<a href="mailto:bsutter@redhat.com">bsutter@redhat.com</a>> wrote:<br>
>>>>>>>><br>
>>>>>>>>> These are not strongly held opinions<br>
>>>>>>>>><br>
>>>>>>>>> One reason to keep Users & Contacts separate is...because that is<br>
>>>> normal for the average enterprise app - your have employees (users) and<br>
>>>> customers (contacts) - employees/users have different roles/privileges from<br>
>>>> customers.<br>
>>>>>>>>><br>
>>>>>>>>> The reason they are separated in the secured (PL) version of<br>
>>>> contacts-mobile-basic is because it simply evolved that way - contacts came<br>
>>>> first - users/roles added after the fact. Ideally we would not modify the<br>
>>>> original too much as it allows a nice learning progression - start with the<br>
>>>> original contacts-mobile-basic, then upgrade to<br>
>>>> contacts-mobile-basic-secured, then upgrade to<br>
>>>> contacts-mobile-basic-secured-cordova (names just made up).<br>
>>>>>>>>><br>
>>>>>>>>><br>
>>>>>>>>> On Apr 23, 2014, at 10:16 AM, Sébastien Blanc <<a href="mailto:scm.blanc@gmail.com">scm.blanc@gmail.com</a>><br>
>>>> wrote:<br>
>>>>>>>>><br>
>>>>>>>>>> Sure !<br>
>>>>>>>>>> Be sure to check this with Joshua as he drives the backend bits<br>
>>>>>>>>>> Sébi<br>
>>>>>>>>>><br>
>>>>>>>>>> Envoyé de mon iPhone<br>
>>>>>>>>>><br>
>>>>>>>>>>> Le 23 avr. 2014 à 15:56, Erik Jan de Wit <<a href="mailto:edewit@redhat.com">edewit@redhat.com</a>> a<br>
>>>> écrit :<br>
>>>>>>>>>>><br>
>>>>>>>>>>> Hi,<br>
>>>>>>>>>>><br>
>>>>>>>>>>> How about merging the User model and the Contact into one entity?<br>
>>>> Seems like they have a lot in common, do we really need 2?<br>
>>>>>>>>>>><br>
>>>>>>>>>>> Cheers,<br>
>>>>>>>>>>> Erik Jan<br>
>>>>>>>>>>><br>
>>>>>>>>>>>> On 23 Apr,2014, at 14:34 , Sébastien Blanc <<a href="mailto:scm.blanc@gmail.com">scm.blanc@gmail.com</a>><br>
>>>> wrote:<br>
>>>>>>>>>>>><br>
>>>>>>>>>>>> We should be using the email as alias and the email should also<br>
>>>> be used as login when registering in the secured part. A registration<br>
>>>> should also trigger the creation of that user / contact in the application.<br>
>>>>>>>>>>>> Author can be left empty By the client and filled by the backend<br>
>>>> .<br>
>>>> <a href="https://github.com/sebastienblanc/jboss-wfk-quickstarts/tree/push_and_securedAuthormust" target="_blank">https://github.com/sebastienblanc/jboss-wfk-quickstarts/tree/push_and_securedAuthormust</a> stay because the receiver must know who sends the message.<br>
>>>>>>>>>>>><br>
>>>>>>>>>>>> Envoyé de mon iPhone<br>
>>>>>>>>>>>><br>
>>>>>>>>>>>>> Le 23 avr. 2014 à 13:35, Erik Jan de Wit <<a href="mailto:edewit@redhat.com">edewit@redhat.com</a>> a<br>
>>>> écrit :<br>
>>>>>>>>>>>>><br>
>>>>>>>>>>>>> Hi,<br>
>>>>>>>>>>>>><br>
>>>>>>>>>>>>> I was working on the aerogear-push-quickstarts for Cordova and<br>
>>>> was wondering what to put for the alias on registration. The version that<br>
>>>> is there now has users that logs in and contacts that are fetched. What<br>
>>>> seems to be missing is that everybody gets all contacts instead of just<br>
>>>> mine (maybe that is fine), but users that sign up for the app are not<br>
>>>> contacts. So when I want to send a message to a specific mobile user they<br>
>>>> are not in my list and there is no way to have to define an alias to send<br>
>>>> to.<br>
>>>>>>>>>>>>><br>
>>>>>>>>>>>>> Also the interface for sending push notifications includes a<br>
>>>> author. I think it would be better if we remove this and let the service<br>
>>>> put in the logged in user. That way you can’t pretend to send a message<br>
>>>> like someone else.<br>
>>>>>>>>>>>>><br>
>>>>>>>>>>>>> What do you think?<br>
>>>>>>>>>>>>><br>
>>>>>>>>>>>>> Cheers,<br>
>>>>>>>>>>>>> Erik Jan<br>
>>>>>>>>>>>>> _______________________________________________<br>
>>>>>>>>>>>>> aerogear-dev mailing list<br>
>>>>>>>>>>>>> <a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
>>>>>>>>>>>>> <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
>>>>>>>>>>>><br>
>>>>>>>>>>>> _______________________________________________<br>
>>>>>>>>>>>> aerogear-dev mailing list<br>
>>>>>>>>>>>> <a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
>>>>>>>>>>>> <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
>>>>>>>>>>><br>
>>>>>>>>>>><br>
>>>>>>>>>>> _______________________________________________<br>
>>>>>>>>>>> aerogear-dev mailing list<br>
>>>>>>>>>>> <a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
>>>>>>>>>>> <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
>>>>>>>>>><br>
>>>>>>>>>> _______________________________________________<br>
>>>>>>>>>> aerogear-dev mailing list<br>
>>>>>>>>>> <a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
>>>>>>>>>> <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
>>>>>>>>><br>
>>>>>>>>><br>
>>>>>>>>> _______________________________________________<br>
>>>>>>>>> aerogear-dev mailing list<br>
>>>>>>>>> <a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
>>>>>>>>> <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
>>>>>>>><br>
>>>>>>>><br>
>>>>>>>> _______________________________________________<br>
>>>>>>>> aerogear-dev mailing list<br>
>>>>>>>> <a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
>>>>>>>> <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
>>>>>>><br>
>>>>>>><br>
>>>>>>> _______________________________________________<br>
>>>>>>> aerogear-dev mailing list<br>
>>>>>>> <a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
>>>>>>> <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
>>>>>><br>
>>>>>><br>
>>>>>> _______________________________________________<br>
>>>>>> aerogear-dev mailing list<br>
>>>>>> <a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
>>>>>> <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
>>>>><br>
>>>>><br>
>>>>> _______________________________________________<br>
>>>>> aerogear-dev mailing list<br>
>>>>> <a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
>>>>> <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
>>>><br>
>>>><br>
>>>> _______________________________________________<br>
>>>> aerogear-dev mailing list<br>
>>>> <a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
>>>> <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
>>>><br>
>>><br>
>>><br>
>>> _______________________________________________<br>
>>> aerogear-dev mailing list<br>
>>> <a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
>>> <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
>>><br>
>><br>
>><br>
>><br>
>> --<br>
>> Matthias Wessendorf<br>
>><br>
>> blog: <a href="http://matthiaswessendorf.wordpress.com/" target="_blank">http://matthiaswessendorf.wordpress.com/</a><br>
>> sessions: <a href="http://www.slideshare.net/mwessendorf" target="_blank">http://www.slideshare.net/mwessendorf</a><br>
>> twitter: <a href="http://twitter.com/mwessendorf" target="_blank">http://twitter.com/mwessendorf</a><br>
><br>
>> _______________________________________________<br>
>> aerogear-dev mailing list<br>
>> <a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
>> <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
><br>
><br>
> --<br>
><br>
> abstractj<br>
> _______________________________________________<br>
> aerogear-dev mailing list<br>
> <a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
<br>
<br>
_______________________________________________<br>
aerogear-dev mailing list<br>
<a href="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/aerogear-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/aerogear-dev</a><br>
</div></div></blockquote></div><br></div></div>