Hi Diego, Thanks a lot for posting the link. I read the document and it was a well-written document. If the document provides more text to review the two pub-sub models and how they may apply to I2RS, it will be more self-contained.
A key proposal from the document, I see, is the introduction of a Message Broker. A main motivation appears to be scalability, i.e., to avoid the P * S problem, where P is the number of publishers and S the number of subscribers. One problem of the document is that it appears to be quite broad, where either applications or routers can publish and subscribe (not sure if routers will subscribe though), and many types (e.g., router/device status changes, app info changes? policy changes) are mentioned. This may imply that the schema of the pub-sub system can be quite complex or very generic. We know generic, well-used systems such as Google Chabby (Zookeeper), and hence I will wait to see the details of any specific proposals, on whether they will apply to ALTO. A concrete issue that I will look for is on how to encode updates of a large data set, e.g., a Network/Cost Map. As a simple, related use case of their scheme, an ALTO Server can be a publisher to push any incremental updates to the Media Broker, who can then handle a large number of subscribers. More complicated use cases or ALTO should develop its own sub-pub mechanism? Happy New Year! Richard On Fri, Dec 27, 2013 at 10:58 AM, Diego R. Lopez <[email protected]> wrote: > Hi, > > Some time ago we discussed about the pros and cons of using Websockets for > implementing server-to-client notifications and I mentioned the possibility > of using a pub-sub schema for creating a general notification framework. > > While reviewing some messages during my end-of-year tidying I came through > this draft: > http://tools.ietf.org/html/draft-camwinget-i2rs-pubsub-sec-00 > contributed to I2RS, that discusses the application of the model in the > access to a programmatic interface to the routing system. I think it > provides a good overview of the model, and that many of the considerations > are applicable to ALTO notifications, and even more to a generalized > topology service. > > Be goode, > > -- > "Esta vez no fallaremos, Doctor Infierno" > > Dr Diego R. Lopez > Telefonica I+D > http://people.tid.es/diego.lopez/ > > e-mail: [email protected] > Tel: +34 913 129 041 > Mobile: +34 682 051 091 > ----------------------------------------- > > > ________________________________ > > Este mensaje se dirige exclusivamente a su destinatario. Puede consultar > nuestra política de envío y recepción de correo electrónico en el enlace > situado más abajo. > This message is intended exclusively for its addressee. We only send and > receive email on the basis of the terms set out at: > http://www.tid.es/ES/PAGINAS/disclaimer.aspx > _______________________________________________ > alto mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/alto > -- -- ===================================== | Y. Richard Yang <[email protected]> | | Professor of Computer Science | | http://www.cs.yale.edu/~yry/ | =====================================
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
