Hi folks, We mentioned that we are going to build our own BaaS product - shouldn't Push Notification services be part of the BaaS product? Also that API should support platform agnostic push notifications.
Cheers~ On Sat, Mar 29, 2014 at 7:49 AM, Samisa Abeysinghe <[email protected]> wrote: > Have we started implementation? > > Thanks, > Samisa... > > > Samisa Abeysinghe > > Vice President Developer Evangelism > > WSO2 Inc. > http://wso2.com > > > > On Fri, Mar 28, 2014 at 5:34 PM, Chan <[email protected]> wrote: > >> Alright. I am +1 to the proposal as long as we mention the proper use of >> the connector (why it should be used to sent messages that are not >> recovered from backend). Also another point is - people shouldn't meditate >> APNS messages in the ESB cause after mediation messages are not available >> to be synced later to the device. >> >> Cheer >> s~ >> >> >> On Friday, March 28, 2014, Rushmin Fernando <[email protected]> wrote: >> >>> *Summary of the thread* >>> ----------------------------------- >>> >>> *The problem* - To write an ESB connector to send Apple push >>> notifications as a result of message mediation. >>> >>> *My solution* - Please refer to the first email of the thread. >>> >>> *Chan's and Niranjan's opinion* - Push notifications should not be used >>> as a way of sending data to apps since push notifications does not support >>> guaranteed delivery. >>> *My comment* - It is a very valid point. But it is our of our concerns >>> since we are only provide the support to send a push notification and its >>> should be user who should decide how to use it in the big picture >>> >>> *Dilshan's opinion* - It is up to the user to how to use the push >>> notification in their apps. ESB should only act as the push notification >>> generator. Device registration should happen in somewhere else >>> *My comment* - Since the connector is not a core part of the ESB we >>> should try to prevent having a dependency to one of our products just for >>> that. >>> But +1 to support 'APN as a service' vendors such as Urban Airship and >>> Push IO since >>> >>> *Technical problems to solve* >>> >>> 1) if we are not thinking to support external vendors such as Push IO or >>> Urban Airship, a user should be able to create an instance of a predefined >>> data structure (refer to the design in the first mail) in the ESB and >>> connector should fetch info from the instance when sending push >>> notifications and store device tokens when self registration of the devices >>> take place. >>> i) How to do manage this data structure and data capturing in ESB ? >>> ii) If its not good to have these data persisted within ESB whats the >>> best possible combination of products we can use ? >>> >>> @Chan, @Niranjan and @Dilshan please correct me if I'm wrong >>> >>> Thanks >>> /rushmin >>> >>> >>> >>> On Fri, Mar 28, 2014 at 2:12 PM, Rushmin Fernando <[email protected]>wrote: >>> >>> Sure Samisa. I will send a summary as soon as possible. >>> >>> >>> On Fri, Mar 28, 2014 at 2:10 PM, Samisa Abeysinghe <[email protected]>wrote: >>> >>> Can we please summarise this thread and move ahead. >>> >>> Thanks, >>> Samisa... >>> >>> >>> Samisa Abeysinghe >>> >>> Vice President Developer Evangelism >>> >>> WSO2 Inc. >>> http://wso2.com >>> >>> >>> >>> On Fri, Mar 28, 2014 at 1:09 PM, Dilshan Edirisuriya >>> <[email protected]>wrote: >>> >>> Hi Rushmin, >>> >>> As far as I see its only matter of exposing the APNS capability through >>> ESB. We don't need to identify its strengths as weaknesses etc (specially >>> we don't have to make it reliable if its not guaranteed delivery). This is >>> just an ESB connector where it facilitate push services. As a developer if >>> I am going to make use of it I will handle my architecture decision within >>> my solution and only use the APNS to send notifications and if necessary to >>> get the list of feedback service. Let the app developer decide what he is >>> going to do with the payload. Whether they use it for notifications or to >>> send some text to the user is none of our business here. Anyway these >>> applications needs to be properly configured in the ESB inorder to work >>> with the apps and the tokens needs to be properly routed through ESB to the >>> external party for storing. >>> >>> To talk about the Chans comments I think its out of scope. Introducing >>> the connector to ESB is just an integration of that service. IMO we don't >>> have handle its weaknesses and come up with a proper solution which beyond >>> its scope (if you really do need then you should come up with your own). >>> This too can cause confusions to the app developers and the entities who >>> consumes this service. +1 for Rushmins approach discussed in the diagram >>> and making it very simple. >>> >>> Regards, >>> >>> Dilshan >>> >>> >>> On Fri, Mar 28, 2014 at 11:00 AM, Rushmin Fernando <[email protected]>wrote: >>> >>> Hi Chan, >>> >>> IMO even without guaranteed delivery we can address the majority of the >>> use cases of APNS usage which is 'push notification as a notification, not >>> as data' . >>> >>> Putting this to simple forms "As result of message mediation people get >>> a notification on their iOS apps which makes them to open the app, and the >>> app is responsible for keep the data in sync when a user uses the app." >>> >>> I think this has enough value to be added as an ESB connector. >>> >>> My suggested usage of feedback usage is not correct. Thank you for >>> pointing that out :-) >>> >>> I had a chat with @Niranjan in the morning and I agree to the point that >>> we should not encourage the users to use APN in ESB as a medium of >>> transporting consistent data to an app (using proper documentation and >>> restrictions in connector con >>> >>> > -- Chan (Dulitha Wijewantha) Software Engineer - Mobile Development WSO2Mobile Lean.Enterprise.Mobileware * ~Email [email protected] <[email protected]>* * ~Mobile +94712112165* * ~Website dulitha.me <http://dulitha.me>* * ~Twitter @dulitharw <https://twitter.com/dulitharw>* *~SO @chan <http://stackoverflow.com/users/813471/chan>*
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
