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 > >
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
