brief project idea

[Yusuke Yamamoto]

Hi,

Let me share my idea of this GSoC project.

What I want to do with this project is to build a framework on top of Twitter4J.
Twitter4J is just a raw and thin wrapper of the Twitter API and there's a gap between actual apps and the library.

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.

Thanks,
--
Yusuke Yamamoto
yus...@mac.com

this email is: [ ] bloggable/tweetable [x] private
follow me on : http://twitter.com/yusuke
subscribe me at : http://samuraism.jp/

[Shao Hong]

Hi Yusuke-san,

Please correct me if I am wrong, so this framework you have in mind is sort of like to combine all the different part of the codes you have into a "cleaner" library where it will handle all the basic problems and this will save the users(developer) on implementing their own way to do it?

[Simeon Maxein]

Hi Shao.

The way I understand it, the framework would not be a replacement for
Twitter4J but would be built on top of it. Twitter4J gives you a very
direct access to the Twitter APIs, and that is what some people need,
but most applications are probably not interested in the nitty gritty
details and would prefer something that already performs some common
work in a sensible way, e.g. providing an always-up-to-date timeline
without querying it from Twitter every time.

I'm not sure in how well I understand the idea of it being a framework
though. Would that imply that it supplies events like "application
startup" to the application?

Simeon

[Yusuke Yamamoto]

Well, it'll be a separate project depending on Twitter4J, not a refactored version of Twitter4J.

I would call it "a framework" because with the framework, your app will be called by the framework instead of calling the Twitter4J's API carefully.

And the framework will take care of timeline, dm, user persistence on behalf of apps.

I hope this will reduce thousands of lines of duplicate code in pre-existing apps.

Thanks,

-- 

Yusuke Yamamoto
yus...@mac.com

this email is: [ ] bloggable/tweetable [x] private
follow me on : http://twitter.com/yusuke
subscribe me at : http://samuraism.jp/

[Zhou Jun]

Can I understand this framework as an engine which will receive the
requests from apps, communicate with twitter4j and export the needed
output back to the apps？

[Andrea Mazzotti]

On Sunday, March 18, 2012 4:08:41 PM UTC+1, @yusuke wrote:

 you need to keep track of the last tweet id you received 

means that the framework has to offer a caching system?

May you tell us other (practical) common problems in Twitter apps developing? 
Just to get an idea on what we need to focus more.

One last thing: i think that a refactoring of Twitter4J would be great, because i see this framework as a better substitute to your library, but a good part of the code will be more or less the same. Am i wrong?

Thank you for your time.

[Alessandro Secco]

So the framework should be a sort of new layer which communicates
directly with Twitter4J managing the problems you explained in the
first message (network difficulties, application restarts and such).
This new framework then communicates with the client apps (which has
no more to keep track of the last tweets). Correct? This in order to
avoid duplicate code and semplifying developer's life.

In my opinion, it is better to make it as a different framework, in
order to maintain modularity.

the problem of taking trace of the last tweets should be shifted from
the application_layer to the this_framework_layer so that client app
developer has no more to manage this. Right?

Alessandro

On 18 Mar, 16:58, Yusuke Yamamoto <yus...@mac.com> wrote:
> Well, it'll be a separate project depending on Twitter4J, not a refactored version of Twitter4J.
> I would call it "a framework" because with the framework, your app will be called by the framework instead of calling the Twitter4J's API carefully.
> And the framework will take care of timeline, dm, user persistence on behalf of apps.
> I hope this will reduce thousands of lines of duplicate code in pre-existing apps.
>
> Thanks,
> --
> Yusuke Yamamoto
> yus...@mac.com
>

> this email is: [ ] bloggable/tweetable [x] privateapplication

[Alexis Mas]

As I understand, this project will act as a "man in the middle" between an app and Twitter4j API. Encapsulating common task that at this time all apps needs to implement. Internally managing all data related with Twitter4j.

[Konrad Reiche]

On Sunday, March 18, 2012 4:58:14 PM UTC+1, @yusuke wrote:

Well, it'll be a separate project depending on Twitter4J, not a refactored version of Twitter4J.

I would call it "a framework" because with the framework, your app will be called by the framework instead of calling the Twitter4J's API carefully.

And the framework will take care of timeline, dm, user persistence on behalf of apps.

I hope this will reduce thousands of lines of duplicate code in pre-existing apps.

The advantage of realizing this proposal as an individual project is that it can be implemented in a clean fashion on top of the existing core library without dealing with the design details of the Twitter4J library, this way you can concentrate completely on the improvements.

In the project ideas you write (1) timeline retrieval (2) persistent cache and (3) event dispatch:

What about rest of the Twitter4J functionality, for instance posting status updates? Should this framework concentrate only on the
timeline and persistence aspects? This would make sense, since the static features of the Twitter4J API seem to work just fine, the problem you have mentioned deal with dynamic aspects of the Twitter API for implementing real-time applications, don't they?

To my mind the framework will then focus mostly on wrapping functionality which would be used through the twitter4j-stream instead, won't it?

 

[Sapan]

Would the project also involve the ability of persisting the collected data to stable storage? If yes, then should it also allow the user to build his own schema or at least let him select which fields in the data he would like to retain? This is because the data is quite large and most of the time, the user might only be interested in only a part of the data. 

Thanks. 

Sapan Diwakar

http://sapandiwakar.in