Interface for the libadblockplus API

src/FilterEngine.cpp

Index: src/FilterEngine.cpp
===================================================================
new file mode 100644
--- /dev/null
+++ b/src/FilterEngine.cpp
@@ -0,0 +1,40 @@
+#include <AdblockPlus.h>
+
+using namespace AdblockPlus;
+
+FilterEngine::FilterEngine(JsEngine& jsEngine) : jsEngine(jsEngine)
+{
+}
+
+void FilterEngine::AddSubscription(Subscription subscription)
+{
+}
+
+void FilterEngine::RemoveSubscription(const Subscription& subscription)
+{
+}
+
+std::vector<Subscription> FilterEngine::GetSubscriptions()
+{
+  return std::vector<Subscription>();
+}
+
+void FilterEngine::UpdateSubscriptionFilters(const Subscription& subscription)
+{
+}
+
+std::vector<Subscription> FilterEngine::FetchSubscriptionList()
+{
+  return std::vector<Subscription>();
+}
+
+bool FilterEngine::FiltersMatch(const std::string& url,
+                                const std::string& contentType) const
+{

[Oleksandr, 2013/03/27 08:37:01]

I guess it probably won't be an issue on Linux, but on Windows I always try to
use std:wstring instead. Especially here, where there is almost guaranteed to be
special chars. Would you oppose to going wstring everywhere?

[Felix Dahlke, 2013/03/27 08:59:18]

That's tricky actually... std::string works fine for UTF-8 on Linux, but not on
Windows. wstring on Linux on the other hand would store 4 bytes per char. That's
not acceptable for us, as we're dealing with lots of filters.

I'll investigate this. We can ignore it for now if we stick to ASCII URLs,
subscription titles and filters.

+  return false;
+}
+
+std::vector<std::string> FilterEngine::GetElementHidingRules() const
+{
+  return std::vector<std::string>();
+}