Github user tdas commented on the pull request:
https://github.com/apache/spark/pull/1717#issuecomment-58725605
Sorry for taking so long to get back on this. I agree with @ezhulenev that
the Twitter4J Authorization has already leaked into public API, so we are
essentially tied with twitter4j for as long as twitter4j survives. :)
I spoke to my @JoshRosen and pwendell, and they agreed that there are two
possible options which are equally okay (specially since we are anyways tied to
Authorization).
1. Either take twitter4j object directly. Low overhead, and API as nice as
twitter4j's FilterQuery, which isnt very good.
2. Or build a facade. Here we take in all the risks if twitter4j changes
subtly. It is hard to test all the functionality that twitter4j's FilterQuery
provide. However it makes the API much nicer.
Another new aspect that I realized is that we want to expose the twitter
stream functionality through Python API
(https://github.com/apache/spark/pull/2538). That will definitely require a
facade (maybe python-only) on FilterQuery causing the same issues as 2.
So I propose actually building that facade. What say?
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
