Is my understanding of the project idea correct?
Jaydeep Joshi
I liked the idea of building an event-driven framework for Twitter4J and
would like to contribute to the project. While going through the source
code of the project, I noticed that currently the modules
twitter4j-async and twitter4j-stream are written in an event-driven
style while twitter4j-core is written in an imperative style. So,
according to my understanding, the idea is to migrate the
imperatively-written modules like twitter4j-core over to an event-driven
model. Am I correct?
Konrad Reiche
Jaydeep Joshi
> As I have understood Yusuke, we should write a new framework, a whole new
> project. This project will have the twitter4j framework as dependency.
framework is already event-based. The only part of the library which is
not event-based is the twitter4j-core module, but I don't understand
why something based on REST and Search APIs needs to be event-based
(because of statelessness of these APIs). If this is indeed what is
needed, then the client apps will themselves have to store the state and
generate events based on changes in this state. On the other hand, the
Streaming API maintains a state and hence, twitter4j-stream is already
event-driven.
>
> In this new framework you specify a whole new API which is directed at
> developers who want to develop Twitter applications with it.
>
> Yes, the Twitter4j has already an event-driven design, whoever it does not
> handle the rough edges of the protocol.
protocol.
Konrad Reiche
> On 03/29/2012 02:36 PM, Konrad Reiche wrote:
>> As I have understood Yusuke, we should write a new framework, a whole
>> new
>> project. This project will have the twitter4j framework as dependency.
> Hi, and thanks for the response. I have a doubt though. The twitter4j
> framework is already event-based. The only part of the library which
> is not event-based is the twitter4j-core module, but I don't
> understand why something based on REST and Search APIs needs to be
> event-based (because of statelessness of these APIs). If this is
> indeed what is needed, then the client apps will themselves have to
> store the state and generate events based on changes in this state. On
> the other hand, the Streaming API maintains a state and hence,
> twitter4j-stream is already event-driven.
I agree with you, I didn't find any functionality in the twitter4j-core
which could be wrapped in a event-driven way. The twitter4j-stream is
already event-driven, but the whole functionality which twitter4j-stream
provides is really thin. When you implement
something, for instance a simple client, you might notice that you have
to deal with problems like network interruption etc.
Yusuke has specified a little about this in the thread "brief project idea":
> For example, if you want to create a simple Twitter client, you may
> want to use the Streaming API (to be precise, it's called "user
> stream") to receive timeline, DMs and such events in realtime.
> Yes, there's already event-driven interfaces.
>
> But once you get into it, you'll notice that you need to deal with
> network difficulties, application restarts and such.
> To fill in the user timeline gap during the application disruption,
> you need to keep track of the last tweet id you received and retrieve
> tweets using the REST API, Search API.
>
> With the framework, application developer will receive events
> transparently and there'll be no need to think about which endpoint to
> use. Instead, the framework will call the app.
> The output of the project would be a combination of the framework
> itself and an example code which uses the framework.
>
> Let me know if you have any question, and feel free to post ideas.
>
Jaydeep Joshi
this framework will act as a sort of bridge between the Twitter4J API
and the application. It will handle details like caching and persistent
storage of user data so that all Twitter4J-based apps can access these
functionalities in a uniform and consistent way rather than each app
trying to re-invent the wheel. But, more importantly,it will provide a
higher-level access to the Twitter4J API, using which app developers
don't have to deal with differences between three twitter APIs and can
access any feature they want in a consistent manner.
Since most Twitter-based apps are more likely to use the real-time
Streaming API, we need a way for the framework to re-establish the
streaming connection using traditional REST and Search APIs each time on
network disconnections, app restarts etc. We will need a way to store
the connection information between the reconnections in a persistent
storage. Have I got the basic idea right or am I missing something?