[chromium-dev] NotificationService doc.

[Simon Hong]

Dear folks,

I wrote a document about chromium's notification service.

https://docs.google.com/document/d/1E_nkSx2g6dnMgcoPUbRk98B0ovnbx9Gu8KLrxS-MVUw/edit

Maybe, This is very easy to most of developers in here.

But, I hope this doc helps to chromium newbies and want to contribute chromium developer document.

It's not perfect.

So, any comment will be appreciate.

Thank you.

Simon

--
======================================

Simon Hong

"Secret of success is consistency to purpose"

[Hongbo Min]

Great! Thanks for your sharing.

On 5月15日, 上午4时42分, Simon Hong <simon.hon...@gmail.com> wrote:
> Dear folks,
>

> I wrote a document about chromium's notification service.https://docs.google.com/document/d/1E_nkSx2g6dnMgcoPUbRk98B0ovnbx9Gu8...

[Bartosz Fabianowski]

I have always been wondering: With this wonderful browser-wide
notification service in place, why does CrosSettings roll its own? The
ExistingUserController register with the browser-wide system and with
CrosSettings separately:

registrar_.Add(this,
chrome::NOTIFICATION_LOGIN_USER_IMAGE_CHANGED,
content::NotificationService::AllSources());
[...]
cros_settings_->AddSettingsObserver(kAccountsPrefShowUserNamesOnSignIn,
this)

The notifications that these produce both end up in
ExistingUserController's Observe() method. Why would CrosSettings not
just use the regular notification service?

- Bartosz

[Julian Pastarmov]

The reason I didn't make CrosSettings not send out its notifications
through the NotificationService is that as far as I know the idea
behind NotificationService is to be used for global broadcast like
events where there might be multiple consumers for a single event or
multiple sources of an event and those should know close to nothing
about each other.

In the case of CrosSettings there are many details which any consumer
should know about the source in order to use the notification so we
can hardly talk about loose coupling. Also there is only one source of
those and this is not intended to change any time soon. Moreover the
CrosSettings object is a singleton and this makes it virtually
available everywhere (except for other singletons of course).

It will be interesting to hear more people on this topic though. What
is your call on when to and when not to add new notifications to the
NotificationService?

[Jochen Eisinger]

On Tue, May 15, 2012 at 10:41 AM, Julian Pastarmov <pasta...@chromium.org> wrote:

The reason I didn't make CrosSettings not send out its notifications
through the NotificationService is that as far as I know the idea
behind NotificationService is to be used for global broadcast like
events where there might be multiple consumers for a single event or
multiple sources of an event and those should know close to nothing
about each other.

In the case of CrosSettings there are many details which any consumer
should know about the source in order to use the notification so we
can hardly talk about loose coupling. Also there is only one source of
those and this is not intended to change any time soon. Moreover the
CrosSettings object is a singleton and this makes it virtually
available everywhere (except for other singletons of course).

It will be interesting to hear more people on this topic though. What
is your call on when to and when not to add new notifications to the
NotificationService?

In my opinion, if you require tight coupling, you should add an Observer interface to CrosSettings (see e.g. base/observer_list.h) for the general pattern.

If the notification observer interface is good enough, you should probably use the notification service instead.

-jochen

 

On May 15, 10:21 am, Bartosz Fabianowski <bar...@google.com> wrote:
> I have always been wondering: With this wonderful browser-wide
> notification service in place, why does CrosSettings roll its own? The
> ExistingUserController register with the browser-wide system and with
> CrosSettings separately:
>
> registrar_.Add(this,
>                 chrome::NOTIFICATION_LOGIN_USER_IMAGE_CHANGED,
>                 content::NotificationService::AllSources());
> [...]
> cros_settings_->AddSettingsObserver(kAccountsPrefShowUserNamesOnSignIn,
> this)
>
> The notifications that these produce both end up in
> ExistingUserController's Observe() method. Why would CrosSettings not
> just use the regular notification service?
>
> - Bartosz

--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
   http://groups.google.com/a/chromium.org/group/chromium-dev