[Webkit-unassigned] [Bug 61140] [GTK] Add HTML5 Notifications support

Wed Jun 22 00:51:16 PDT 2011

https://bugs.webkit.org/show_bug.cgi?id=61140

--- Comment #22 from Alexandre Mazari <scaroo at gmail.com>  2011-06-22 00:51:16 PST ---
(In reply to comment #20)

Hi !

> I think that using interfaces will greatly complicate using this for no real >good reason.

Well, I dont really buy this argument, on webkit part, signals imply the generation of new marshaller, modifies existing code (with eventual side-effects) and makes WebKitWebView source even longer to human parse and test.

The same apply on client code, requiring interface implementation enforce data+behaviour locality, making it easier to share state between calls, finding your way to the related code and write unit tests for isolated components.

C/GObject interface adds some ceremonial for sure, but the longer term advantage regarding maintenance overshadows this initial step. Cumbersome to write, nice to maintain.

Also this is greatly mitigated when the client code uses language bindings with true object orientation.

Making the (nice and well-thought) object-oriented model of WebKit/WebCore a procedural one by flattening the type hierarchy souds like a step backward IMHO.

Shouldn't we strive to make the devs' (both UA and webkit-gtk contributors) life easier by:

- increasing their productivity by
  * avoiding them getting lost in 500+ loc sources
  * wasting time trying to find the reason their signals handler is not
    called, often a bloody typo when the compiler can do it better.
  * avoiding creating temp structures to pass data around multiple invocations
    and handling their reffing rightly.

- making them more confident in their code by
  * making building the security harness that are unit tests easier
  * avoiding in-place modifications which might introduce side-effects.

Oh this s turning into a OO manifesto, I d better stop that before a functional programmer comes chime in ;)

But one a more general aspect, I kinda think that the complexity and time-consuming nature of the GObject type system (in C) caused an abuse of signals usage throughout the platform (gnome), favouring a procedural paradigm for application development. Still signals are a great tools for watching unexpected hardware, network and user events when multiple parties are interested in. Outside that scope delegation is leaner, faster and more robust IMHO.

> I mostly agree with Xan: I'd rather have policy decisions go through WebView like we do for the rest,

Consistency sounds like a convincing argument. If the two of you really feel that way, I'll go back to the signal implementation for consistency-sake.

But in the longer term do we want to keep this status quo ?

> and I am pretty sure WebKitWebNotification is duplicating the DOM object, so enabling it sounds like a good first step =).
>

See the previous comment, the dom notification lakes essential data. Maybe I should subclass it and add what's missing.

> > Source/WebCore/ChangeLog:10
> > +        * notifications/Notification.cpp: Use the same codepath as Qt, set the stqte before showing.
> 
> stqte->state
>
Will Fix. 

> > Source/WebKit/gtk/ChangeLog:18
> > +        on Gtk's NotificationPresenter implementation<
> 
> s/<//
Itoo.

Thanks for your time and effort!

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.