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