Re: [alto] Pub-sub interfaces

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 <diego@tid.es> 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: diego@tid.es
> 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
> alto@ietf.org
> https://www.ietf.org/mailman/listinfo/alto
>

-- 
-- 
 =====================================
| Y. Richard Yang <yry@cs.yale.edu>   |
| Professor of Computer Science       |
| http://www.cs.yale.edu/~yry/        |
 =====================================