Hi Carlos, Great that with the transition to wk2, we have the occasion to rethink a bit the API.
As stated in https://bugs.webkit.org/show_bug.cgi?id=61140#c22 , we might use this occasion to rethink our current (over) usage of signals and properties. WebView API currently suffers, IMHO, from having so much unrelated data and codepath delegation. This do not enforce a clean OO model on both webkit's and API user's code. Both of them going mostly procedural, have huge LoC count and fiddle with data sharing. Also we currently flatten the WebCore object model by putting so much in one class. Also, most of those signals will have only one listener in the client code, rendering signals multiplexing/marshalling useless. We should enforce the user code to be smaller independent testable parts instead. Related delegators (currently signals) could go into interface instead. Implementations of those would then be provided and used by the webview. Don't call us, we call you... So for example we could have the following instead of the current signals: interface WebKitNotificationPresenter { def authRequested (...); def checkAuth (...); def showNotification (...); def cancleNotification (...); } and WebKitWebView::setNotificationPresenter (WebKitNotificationPresenter) The API user would then provide an implementation of the interface. Advantages: - The code and data related to the topic (here notifications) are isolated - the class can be tested separately - the code is more readable, so are stacktraces - no more intermediate struct types to pass as user_data to callbacks, everything is in the class - limoit the scope of sides effects - the lifecycle of such a delegator class is easier to handle than multiple data structures. Cons: - GObject interface implementation is cumbersome, but this is mitigated by bindings I have the feeling signals have bee overused in webkit (and elsewhere in the platform) for this exact reason. C/GObject low-level complexity often divert dev from nice oo design for convenience. But that make testing and maintaining harder, I guess. OT: Vala looks like an interesting solution to alleviate that. > _______________________________________________ > webkit-gtk mailing list > [email protected] > http://lists.webkit.org/mailman/listinfo.cgi/webkit-gtk _______________________________________________ webkit-gtk mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-gtk
