[wishlist] twitter/identi.ca operation could be more bandwidth friendly

Bug #311793 reported by zzz on 2008-12-27
28
This bug affects 4 people
Affects Status Importance Assigned to Milestone
Gwibber
Wishlist
Ryan Paul
Nominated for 1.2 by Bill McGonigle
Nominated for 2.0 by Bill McGonigle
Nominated for 3.0 by Bill McGonigle

Bug Description

It appears that gwibber currently polls the twitter/ident.ica timelines on an interval, requesting all messages up to the given count. It then replaces the message_store.

Ideally gwibber should use the since_id parameter along with the most recent tweet id in the message store to request only statuses that is hasn't seen before. It should then prepend these to the message store before trimming it to the count size that it previously requested, before refreshing and displaying.

Speedboy (speedboyii) wrote :

This would be a handy feature! Not only for bandwidth but also because if you now get a bad connection between an interval gwibber stops showing all of the previous messages.

Changed in gwibber:
assignee: nobody → oldman
importance: Undecided → Wishlist
status: New → Confirmed
zzz (oldman-deactivatedaccount) wrote :

experimental branch attached, please test!

Changed in gwibber:
status: Confirmed → In Progress
Speedboy (speedboyii) wrote :

I get twitter retrieve responses errors in that build and it doesn't show any tweets. (it does show identi.ca and jaiky posts)
-"TypeError: 'NoneType' object must be a strong or a number and not a 'NoneType'" (shows this error right from the start when you start gwibber)
-"TypeError: 'NoneType' object is not iterable" (shows this after the first refresh and it keeps on giving this one everytime it refreshes)

zzz (oldman-deactivatedaccount) wrote :

that's strange.. i'm running it right now and it is doing fine

zzz (oldman-deactivatedaccount) wrote :

... although i'm not yet happy with performance, probably the list subscripting is performing slowly

zzz (oldman-deactivatedaccount) wrote :

or actually more likely the 200 iterations of the addMessages javascript

Speedboy (speedboyii) wrote :

I got it working by changing the value of messages (the global one) from None to "" in twitter.py.

zzz (oldman-deactivatedaccount) wrote :

Thanks, tidied up based on your feedback. Hopefully should be more robust now.

Speedboy (speedboyii) wrote :

I tried the tidied up version on my laptop and it works! And on the desktop it was still working without any of the problems the regular gwibber bzr version has, nice work!

Evan McClain (aeroevan) wrote :

Apparently something breaks when receive_count is None:
evan@~/src/Net/Twitter/bug-311793]» ./run
/home/evan/src/Net/Twitter/bug-311793/gwibber/microblog/support/facelib.py:47: DeprecationWarning: the md5 module is d
  import md5
20 new tweets since last_message_id -1
Traceback (most recent call last):
  File "/home/evan/src/Net/Twitter/bug-311793/gwibber/microblog/twitter.py", line 161, in receive
    for data in self.get_messages():
  File "/home/evan/src/Net/Twitter/bug-311793/gwibber/microblog/twitter.py", line 127, in get_messages
    messages = (new_messages + (messages or []))[0:int(self.account["receive_count"]) or 20]
TypeError: int() argument must be a string or a number, not 'NoneType'

It looks like a typo int(None) vs int(None or 20). The attached patch fixes it for me.

Thanks for the patch. Accepted and pushed up to branch.

p.s. have merged latest from lp:gwibber into this branch, note that ./run has been removed now and for testing branches the same functionality is now found in ./bin/gwibber (i.e., adding local files to python sys.path)

When will we see that in Gwibber?

Ryan Paul (segphault) wrote :

The since_id value is now used for Twitter, Identi.ca, and Facebook.

Changed in gwibber:
assignee: Dominic Evans (oldman) → Ryan Paul (segphault)
status: In Progress → Fix Committed
Omer Akram (om26er) wrote :

Fixed as per last comment in 2.29.91

Changed in gwibber:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Related questions

Patches