Filter changed callback

lib/filterUpdateRegistration.js

 /*
  * This file is part of Adblock Plus <http://adblockplus.org/>,
  * Copyright (C) 2006-2013 Eyeo GmbH
  *
  * Adblock Plus is free software: you can redistribute it and/or modify
  * it under the terms of the GNU General Public License version 3 as
  * published by the Free Software Foundation.
  *
  * Adblock Plus is distributed in the hope that it will be useful,
  * but WITHOUT ANY WARRANTY; without even the implied warranty of
  * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
  * GNU General Public License for more details.
  *
  * You should have received a copy of the GNU General Public License
  * along with Adblock Plus.  If not, see <http://www.gnu.org/licenses/>.
  */
 
 let {FilterNotifier} = require("filterNotifier");
-let {Synchronizer} = require("synchronizer");
 
-FilterNotifier.addListener(function(action, subscription)
+FilterNotifier.addListener(function(action, item)
 {
-  switch (action)

[Andrey Novikov, 2013/06/18 11:48:28]

I didn't change the logic of the current Android application. May be it has to
be modified in some way to be more uniform?

[Wladimir Palant, 2013/06/18 15:02:15]

Yes, this definitely needs to be more generic - this is a general-purpose
library. One way to would be sending all status changes to the C++ code. That's
likely unnecessary overhead however, there can be lots of messages. The other
option is passing in a filter - what messages should be sent to the caller. You
will need to add a function to api.js - C++ doesn't run any complicated JS code.
The list of messages definitely shouldn't be hardcoded here.

[Andrey Novikov, 2013/06/25 08:08:02]

So, I see no reason to complicate things with some filter, C code can deal with
filtering by itself. Yes?

[Felix Dahlke, 2013/06/25 08:21:58]

IMO yes. It's simpler, and I doubt there'll be any noteworthy overhead if we
just forward all events.

[Wladimir Palant, 2013/06/25 08:44:40]

JS to C++ calls always mean overhead and we will be producing lots of them here.
Still, probably not worth it unless we see that this indeed has a performance
impact.

-  {
-    case "subscription.lastDownload":
-    case "subscription.downloadStatus":
-      let status = "synchronize_never";
-      let time = 0;
-      if (Synchronizer.isExecuting(subscription.url))
-      {
-        status = "synchronize_in_progress";
-      }
-      else if (subscription.downloadStatus && subscription.downloadStatus != "synchronize_ok")
-      {
-        status = subscription.downloadStatus;
-      }
-      else if (subscription.lastDownload > 0)
-      {
-        time = subscription.lastDownload;
-        status = "synchronize_last_at";
-      }

[Wladimir Palant, 2013/06/18 15:02:15]

This processing should be done in the C++ code, the code here should just send
the parameters unchanged.

-      _triggerEvent("filterChange", subscription.url, status, time);
-      break;
-  }
+  _triggerEvent("filterChange", action, item);
 });