Re: [alto] Pub-sub interfaces

Hi Diego,

On Wed, Jan 1, 2014 at 4:44 PM, Diego R. Lopez <diego@tid.es> 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 <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/        |
>  =====================================
>
>
>
> --
> "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
>

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