Hi Diego, On Wed, Jan 1, 2014 at 4:44 PM, Diego R. Lopez <[email protected]> wrote:
> > I agree the document is rather general: bear in mind it is a first > statement addressed to a WG like I2RS, with very broad goals and in its > initial stages. My intention was precisely to provide it as an initial > reference for the ALTO crowd to consider and discuss on use cases. The one > you mention is the one I had in mind. More complicated ones could include > hierarchical aggregation, composition of information from different > servers, or data filtering driven by policies. I guess this could be > applicable in inter-domain scenarios. > > Very interesting additional use cases (aggregation, composition, and filtering all make sense, for example in the case of interdomain). I remember previous discussions on building such capabilities (e.g., filtering) on top of ALTO, either using the ALTO protocol (e.g., by extension within ALTO), or using a completely different protocol (e.g., the proposed scheme). One interesting question to think about, is what we need to change ALTO, if any, if we use the second, which hopefully has a lower amount of work than the first. Personally, I am fine with using a generic pub-sub service and then multiple services (e.g., ALTO) can use it. If the generic service can handle the ALTO's schema is a key question. Cheers, Richard Be goode and have an Extremely Goode New Year, > > On 31 Dec 2013, at 03:05 , Y. Richard Yang wrote: > > 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/ | > ===================================== > > > > -- > "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 > -- -- ===================================== | 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
