Menu
▾
▴
gmailagent-devel — List should be used by developers aswell as users
You can subscribe to this list here.
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(6) |
Jun
(42) |
Jul
(1) |
Aug
(1) |
Sep
(74) |
Oct
(1) |
Nov
(3) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Stas Z <sta...@gm...> - 2006-07-15 18:07:10
|
On 7/15/06, Andrew Fuller <mac...@gm...> wrote: > I just came across your GMailAgent today and want to say "thanks" and > also suggest you put it up on kde-apps.org to get a bit more exposure. > I think many people would appreciate it who have never heard of it > yet. I will look into it, thanks. > btw- I first sent this to gma...@us..., but got a message > back that it failed permanently (without a reason). Perhaps you don't > really want to use that email on your homepage :) That mail address is totally wrong :-( I will change it. Cheers, Stas Zytkiewicz -- I disapprove of what you say, but I will defend to the death your right to say it. Voltaire French author, humanist, rationalist, & satirist (1694 - 1778) |
|
From: Stas Z <sta...@gm...> - 2005-11-27 05:46:21
|
Thanks. Stas On 11/26/05, Waseem S. Daher <wd...@mi...> wrote: > I will take a second look and apply these patches on Monday, unless > someone wants to first (on vacation, so I don't have access to my linux > box) > > - W > > On Thu, 24 Nov 2005, Stas Z wrote: > > > ---------- Forwarded message ---------- > > From: SourceForge.net <no...@so...> > > Date: Nov 24, 2005 2:05 AM > > Subject: [libgmail - Open Discussion] patches sitting unused > > To: no...@so... > > > > > > > > Read and respond to this message at: > > https://sourceforge.net/forum/message.php?msg_id=3D3442075 > > By: psavo > > > > Is there a reason that patches attached in 'patches' section sit unused= ? > > > > I'm personally interested in patch 1064179, saving all info about threa= d, as > > I couldn't find any other way to access that information. At some point= it was > > in debian, but apparently got dropped. > > I use it to display information about new messages in a Gmail Notifier = style > > application wmgmail. > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi= les > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick > _______________________________________________ > Gmailagent-devel mailing list > Gma...@li... > https://lists.sourceforge.net/lists/listinfo/gmailagent-devel > -- A nation that continues year after year to spend more money on military def= ense than on programs of social uplift is approaching spiritual doom. Martin Luther King, Jr. |
|
From: Waseem S. D. <wd...@MI...> - 2005-11-26 06:48:41
|
I will take a second look and apply these patches on Monday, unless someone wants to first (on vacation, so I don't have access to my linux box) - W On Thu, 24 Nov 2005, Stas Z wrote: > ---------- Forwarded message ---------- > From: SourceForge.net <no...@so...> > Date: Nov 24, 2005 2:05 AM > Subject: [libgmail - Open Discussion] patches sitting unused > To: no...@so... > > > > Read and respond to this message at: > https://sourceforge.net/forum/message.php?msg_id=3442075 > By: psavo > > Is there a reason that patches attached in 'patches' section sit unused? > > I'm personally interested in patch 1064179, saving all info about thread, as > I couldn't find any other way to access that information. At some point it was > in debian, but apparently got dropped. > I use it to display information about new messages in a Gmail Notifier style > application wmgmail. |
|
From: Stas Z <sta...@gm...> - 2005-11-24 17:51:59
|
---------- Forwarded message ---------- From: SourceForge.net <no...@so...> Date: Nov 24, 2005 2:05 AM Subject: [libgmail - Open Discussion] patches sitting unused To: no...@so... Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=3D3442075 By: psavo Is there a reason that patches attached in 'patches' section sit unused? I'm personally interested in patch 1064179, saving all info about thread, a= s I couldn't find any other way to access that information. At some point it = was in debian, but apparently got dropped. I use it to display information about new messages in a Gmail Notifier styl= e application wmgmail. ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=3D388073 -- A nation that continues year after year to spend more money on military def= ense than on programs of social uplift is approaching spiritual doom. Martin Luther King, Jr. |
|
From: Stas Z <sta...@gm...> - 2005-10-13 18:08:33
|
Hello, Just released version 0.7.2. This release fixes some minor bugs. Stas -- A nation that continues year after year to spend more money on military def= ense than on programs of social uplift is approaching spiritual doom. Martin Luther King, Jr. |
|
From: Stefan P. <da...@po...> - 2005-09-29 21:01:08
|
Hi Stas,=20 Am Donnerstag 29 September 2005 20:33 schrieb Stas Z: > On 9/29/05, Stas Z <sta...@gm...> wrote: > > > However before doing anything wrong again, I'd like to hear your > > > opinions about this. > > > > Cool, I will test you patches tonight (I'm in GMT+2) > > OK, I've applied the patches and they work great :-) Thanks for your efforts and for testing. > The bugs related to the syntax highlighting and the localization > of the worldbuilder are fixed now, thanks. You're welcome ;) > > When testing the worldbuilder I noticed a bug in the 'beeper set' dialog. > You could choose the number of beepers the robot would carry but > they never get set in the program. > This is fixed also. Great! > > So your patches are applied and together with my fix the worldbuilder > seems Breezy ready. I committed the changes to CVS. > > Let me know if you think the gvr currently in CVS is ready for Breezy. It definitely is more than ready for breezy. Thanks again for all your work! I already got ok to break the freeze and will upload the new version of gvr= =20 tomorrow ;) P.S.: If you are interested, the latest source-package is at: http://revu.tauware.de/details.py?upid=3D664 P.P.S.: I just resent the message, as gmailagent-devel rejected my mail=20 because it suspected it to be spam. Cheers and thanks for your collaboration, Stefan. |
|
From: Stas Z <sta...@gm...> - 2005-09-29 19:32:39
|
On 9/29/05, Stas Z <sta...@gm...> wrote: > > However before doing anything wrong again, I'd like to hear your opinio= ns > > about this. > Cool, I will test you patches tonight (I'm in GMT+2) OK, I've applied the patches and they work great :-) The bugs related to the syntax highlighting and the localization of the worldbuilder are fixed now, thanks. When testing the worldbuilder I noticed a bug in the 'beeper set' dialog. You could choose the number of beepers the robot would carry but they never get set in the program. This is fixed also. So your patches are applied and together with my fix the worldbuilder seems Breezy ready. I committed the changes to CVS. Let me know if you think the gvr currently in CVS is ready for Breezy. PS, SF only updates the anonymous CVS every few hours or so so I attached the changed gvr files which are currently in CVS. Cheers, Stas -- A nation that continues year after year to spend more money on military def= ense than on programs of social uplift is approaching spiritual doom. Martin Luther King, Jr. |
|
From: Stas Z <sta...@gm...> - 2005-09-29 15:24:56
|
On 9/29/05, Stefan Potyra <da...@po...> wrote:
> Hi again,
>
> thanks for your fast replies.
> After hearing pros and cons to localization of the language files, I'd li=
ke to
> propose another solution for the ubuntu-package:
>
> I imported the patch from cvs[1] (and dropped some debug stuff in it) to
> support highlighting localized keywords and wrote a patch to have
> worldbuilder generate localized files[2].
>
> However before doing anything wrong again, I'd like to hear your opinions
> about this.
Cool, I will test you patches tonight (I'm in GMT+2)
Thanks, it's always nice to get patches alongside bug reports :-)
> [1]: This is slightly different then the cvs-version, I also needed to ch=
ange
> EditorWindos.py:402 from
>
> self.kwords =3D [L2U(_('Robot')), L2U(_('Wall')), L2U(_('Beepers')),
> L2U(_('Size'))]
>
> to
>
> self.kwords =3D [L2U(_('ROBOT')).title(), L2U(_('WALL')).title(),
> L2U(_('BEEPERS')).title(), L2U(_('SIZE')).title()]
Hmm, with a properly translated po file that won't be needed but it
could serve as a backup for partial translated po files :-)
Thanks,
Stas
--
A nation that continues year after year to spend more money on military def=
ense
than on programs of social uplift is approaching spiritual doom.
Martin Luther King, Jr.
|
|
From: Stas Z <sta...@gm...> - 2005-09-28 20:28:18
|
On 9/28/05, Stefan Potyra <da...@po...> wrote: > I just read over your mail and the mailing list and would like to give so= me > further thoughts on language support: > > If language support is enabled, > (1) files from worldbuilder cannot be loaded > (2) keywords aren't highlighted. > (3) language/world files aren't exchangable > (4) the package examples are mostly in english, which cannot be used then > > You've discussed (3) quite long on the mailing list, and I'd rate this as= a > wishlist bug. Indeed, we started to work on that. Don't know when it's ready. > I'd rate (4) a little bit higher, as I tend to look at examples at first,= if I > want to get started with something. However this could be solved easily b= y > including more localized examples in the package. Your right, I will try to translate some of the examples. > For (2) I'd just say that this is a minor bug at most. That's already fixed in CVS. > So the real reason to drop language support would be (1). > > However after giving this a second thought I am not sure if dropping lang= uage > support has been a mistake. Does the benefit of beeing able to use the > worldbuilder outweigh language support? No, it doesn't and I consider (1) to be a bug which should be fixed asap. That also the reason I suggested that you left the language support out, considering it's going into a stable release soon. (Breezy) > To put it short, I'm really clueless if I did the right or wrong thing an= d I'd > appreciate to hear your opinion on this. Al things consider, I would say you did right dropping some of the language support. > (Btw.: I'd really like to go in sync to debian again, as this will not on= ly > save us merging work in the future, but have a real maintainer with > experience for this package care for it.) I think you should contact Sergio personally and discuss this with him. Besides, gvr is a learning tool, it's development was meant as a learning t= ool, it's used as a learning tool, perhaps it's packaging can also be a learning tool :-) Cheers, Stas -- A nation that continues year after year to spend more money on military def= ense than on programs of social uplift is approaching spiritual doom. Martin Luther King, Jr. |
|
From: Stas Z <sta...@gm...> - 2005-09-28 18:13:42
|
Hello I've released a new version of GmailAgent, version 0.7. This version includes support for the new contacts frontend called GContactsAgent. It now also uses the official libgmail instead of the cunstom version. A new addition to this project is GContactsAgent or gca for short. This is a graphical frontend for the Gmail contacts. It can be run as a standalone GUI or used from within GA. Website: http://gmailagent.sf.net Download: http://gmailagent.sf.net/download Cheers, Stas -- A nation that continues year after year to spend more money on military def= ense than on programs of social uplift is approaching spiritual doom. Martin Luther King, Jr. |
|
From: Richard J. <jo...@gm...> - 2005-09-26 12:50:21
|
On 9/26/05, Stas Z <sta...@gm...> wrote: > On 9/26/05, Richard Jones <jo...@gm...> wrote: > > > Thanks for that, gmailfs users everywhere will thanks you (all 2 or 3 > > of them :-) ). > Are you sure, a quick look into the Debian popularity contest shows > that they recorded > 158 persons which installed it :-) > And that only for Debian users who participate in the popularity contest. > Interesting, I guess I judge by the number of complaints I get when Google changes something. Maybe seb is heading off most of those complaints :-) > > > I also added a new method called 'getUnreadMsg' which returns the inb= ox messages > > > marked 'unread'. > > > > > I don't have a strong opinion on this, I dont use this call in > > gmailfs, however from an API point of view it might be better to add > > a getUnreadMessagesByFolder and have some kind of strategy of dealing > > with the lockdown issue. > That is probably better indeed, thanks. > > > Can you only get the first page and then > > load the others on demand when the user tries to iterate over them? > Perhaps, but it should also be possible when libgmail is run in some sort= of > automated process or from a script. > By user I meant API user. This idea only really helps if they are doing work with the messages whilst iterating overthem otherwise they are still likely to get locked out. I guess the only real option here is to introduce artificial pauses if you detect the API user iterating too quickly (assuming that what is "too quickly" can be easily pre-determined). Regards, Richard. |
|
From: Stas Z <sta...@gm...> - 2005-09-26 12:47:17
|
Hello, just released a new version of libgmail, 0.1.3.2 This release fixes some minor bugs in the handleing of the messages thread and also the return value of len(thread) Stas -- A nation that continues year after year to spend more money on military def= ense than on programs of social uplift is approaching spiritual doom. Martin Luther King, Jr. |
|
From: Stas Z <sta...@gm...> - 2005-09-26 11:33:06
|
On 9/26/05, Stas Z <sta...@gm...> wrote: > > > gmailfs, however from an API point of view it might be better to add > > a getUnreadMessagesByFolder and have some kind of strategy of dealing > > with the lockdown issue. > That is probably better indeed, thanks. Better, getUnreadMessagesByLabel. The only folder with unread messages would be the inbox. I assuming noone wants to read the spam folder :-) Stas -- A nation that continues year after year to spend more money on military def= ense than on programs of social uplift is approaching spiritual doom. Martin Luther King, Jr. |
|
From: Stas Z <sta...@gm...> - 2005-09-26 11:29:59
|
On 9/26/05, Richard Jones <jo...@gm...> wrote: > Thanks for that, gmailfs users everywhere will thanks you (all 2 or 3 > of them :-) ). Are you sure, a quick look into the Debian popularity contest shows that they recorded 158 persons which installed it :-) And that only for Debian users who participate in the popularity contest. > > I also added a new method called 'getUnreadMsg' which returns the inbox= messages > > marked 'unread'. > > > I don't have a strong opinion on this, I dont use this call in > gmailfs, however from an API point of view it might be better to add > a getUnreadMessagesByFolder and have some kind of strategy of dealing > with the lockdown issue. That is probably better indeed, thanks. > Can you only get the first page and then > load the others on demand when the user tries to iterate over them? Perhaps, but it should also be possible when libgmail is run in some sort o= f automated process or from a script. Stas -- A nation that continues year after year to spend more money on military def= ense than on programs of social uplift is approaching spiritual doom. Martin Luther King, Jr. |
|
From: Richard J. <jo...@gm...> - 2005-09-26 10:03:46
|
On 9/26/05, Stas Z <sta...@gm...> wrote: > Hello > > I fixed the bug in the return value of a 'len' call to a message > thread, it now returns > 0 again when the thread is empty. It will be in the next release along > with some other > small fixes. I will release it this afternoon. > Thanks for that, gmailfs users everywhere will thanks you (all 2 or 3 of them :-) ). > I also added a new method called 'getUnreadMsg' which returns the inbox m= essages > marked 'unread'. > > I was wondering if we should change the way getMessagesbyFolder works. > Perhaps we return only the unread messages when the inbox is chosen. > The problem with calling getMess... with the 'inbox' is that on larger > accounts you > will get a "lockdown" due to the many calls to the Gmail servers. > > I think we also should limit the number of page call to avoid lockdowns. > > I would really like to hear any comments or ideas about this. > I don't have a strong opinion on this, I dont use this call in gmailfs, however from an API point of view it might be better to add a getUnreadMessagesByFolder and have some kind of strategy of dealing with the lockdown issue. Can you only get the first page and then load the others on demand when the user tries to iterate over them? Regards, Richard. |
|
From: Stas Z <sta...@gm...> - 2005-09-26 09:41:21
|
Hello I fixed the bug in the return value of a 'len' call to a message thread, it now returns 0 again when the thread is empty. It will be in the next release along with some other small fixes. I will release it this afternoon. I also added a new method called 'getUnreadMsg' which returns the inbox mes= sages marked 'unread'. I was wondering if we should change the way getMessagesbyFolder works. Perhaps we return only the unread messages when the inbox is chosen. The problem with calling getMess... with the 'inbox' is that on larger accounts you will get a "lockdown" due to the many calls to the Gmail servers. I think we also should limit the number of page call to avoid lockdowns. I would really like to hear any comments or ideas about this. Cheers, Stas -- A nation that continues year after year to spend more money on military def= ense than on programs of social uplift is approaching spiritual doom. Martin Luther King, Jr. |
|
From: Stas Z <sta...@gm...> - 2005-09-25 15:17:57
|
Hello, We now have a libgmail mailinglist so I suggest that anybody who has an interest in libgmail subscribes to that list (also). The list is intended for developers as well as users. libgmail mailinglist: http://lists.sourceforge.net/lists/listinfo/libgmail-developer Stas -- A nation that continues year after year to spend more money on military def= ense than on programs of social uplift is approaching spiritual doom. Martin Luther King, Jr. |
|
From: Richard J. <jo...@gm...> - 2005-09-25 13:12:40
|
On 9/24/05, Stas Z <sta...@gm...> wrote:
> Just realize that you might not be subscribed to the mailinglist :-)
>
Thanks Stas, I'm subscribed now :-)
> On 9/22/05, Richard Jones <jo...@gm...> wrote:
>
> > > I suspect because gmailfs interacts with the internal message threads
> > > rather then
> > > through an API, it gets into trouble because there are changes to the=
se internal
> > > class attributes.
> [....]
> > You are quite correct I shouldn't be messing with the internal class
> > attributes, however I don't think this is the core problem here
> > (although it doesn't help).
> >
> > If you look at the GmailSearchResult initialisation method below:
> [...]
> > except IndexError:
> > print "Empty account"
> [...]
> > Based on the error message "Empty Account" you seem to be assuming
> > that threadsInfo[0] will be an illegal index only when the account is
> > empty. In fact there appears to be a much more common reason for
> > threadsInfo to be empty, this seems to occur (based on my limited
> > testing) when the query returns no results.
> Your right the message is wrong it should say "Empty thread"
>
Its not just the message that is a problem, the major problem is the
other one I mentioned that len() is going to return the wrong value.
Users will not expect len to return 1 for an empty thread, i.e. this
is an API breakage not just a change in internal behaviour.
> [...]
> > attributes, I couldn't find an API supported way of directly indexing
> > particular thread and message numbers, please tell me if I'm missing
> > something).
> Well I guess if you using libgmail in such a way as you do in gmailfs
> your better of with a abstraction layer that can function as a interface
> to libgmail.
>
> My proposal to you as your a "libgmail-poweruser" is this;
> If you describe which methods you need then we will provide a object
> that act as a interface between gmailfs and libgmail.
> We will maintain this class so that any change we make to libgmail
> will also be changed in the interface class.
> We will put it into a module of it's own so that it doesn't affect the 'n=
ormal'
> libgmail usage.
>
> For example:
> You want to know how many messages there are in a thread.
> So you want to do something like:
>
> from FsInter import FsInter # This is the abstraction class
> ga is FsInter.GMAccount("name","pass")
> ga.login()
> thread =3D ga.getMessages.......
> ....
> def getinodemsg():
> ......
> ......
> return thread.NumberOf Messages()
>
> Or something like that.
> Then you don't have to care about our changes :-)
>
> We will make sure that the abstraction class gets to the internals in
> a proper way.
>
Thanks Stas, some interfaces to help me avoid messing with the
internals would be cool. However I don't think its necessary to add
these as a surrounding abstraction class. GmailThread and others
already have the len call defined for them so the NumberOfMessages()
call should do the same thing as the already available len. However
what would be useful is to have an extra method getThreadAt() which
takes the index of the thread to get and return the gmail thread
object. A similar method for each thread which returns the message at
a particular index (getMessageAt()) would also be useful.
I think this type of stuff is generally useful enough to be placed
directly on the objects in question rather than adding them to a
wrapper class.
The change I'd really like to see in the short term however is making
len return 0 for GmailSearchResult objects that have no results. This
returns to the original behaviour and keeps the contract of the old
API. This also means that existing gmailfs users shouldn't need a new
version of gmailfs when downloading the newest libgmail (but I'm still
happy to make a new gmailfs if the getThreadAt etc methods can be
added).
Regards,
Richard.
|
|
From: Stas Z <sta...@gm...> - 2005-09-24 18:34:31
|
On 9/24/05, follower <fol...@my...> wrote: > > > > ---------- Forwarded message ---------- > From: Evan Jones <ej...@uw...> > To: fol...@my... > Date: Fri, 23 Sep 2005 00:43:50 -0400 > Subject: libgmail: Tiny fix > Using the latest CVS version of libgmail, I get the following error > when I try to use gcp: > > Traceback (most recent call last): [...] > IndexError: list index out of range [..] > Hence, if you change line 623 from this: > > resultInfo =3D items[D_SENDMAIL_RESULT] > > to this: > > resultInfo =3D items[D_SENDMAIL_RESULT][0] > > it works. Hi Evan. Thank you very much for the fix, it will be in the next release of libgmail= . > I wonder if this means that a more general fix is required in > _parsePage? No, the the page parser is changed due to a very serious security bug. The result is that all the data from the parser is now in the same format. (list(s) in a list) The downside is that, as you noticed, not all the code is changed to handle the new format. Regards, Stas Zytkiewicz -- A nation that continues year after year to spend more money on military def= ense than on programs of social uplift is approaching spiritual doom. Martin Luther King, Jr. |
|
From: Stas Z <sta...@gm...> - 2005-09-23 14:10:44
|
---------- Forwarded message ---------- From: Stas Z <sta...@gm...> Date: Sep 23, 2005 4:00 PM Subject: Re: libgmail.py To: Greg Wilson <gvw...@cs...> On 9/23/05, Greg Wilson <gvw...@cs...> wrote: > I'm using the ActiveState Python installer on Windows, so I don't know. > How would I find out? A bit of googling turns up this: "" The default distribution of ActiveState ActivePython does not include support for SSL in the socket library. This means that, amongst other things, you cannot use the HTTPSConnection object for getting web pages via HTTPS. "" Taken from: http://www.junkheap.net/projects/python-windows-ssl/python-windows-ssl.html It also contains instructions on how to get ssl support. > Thanks very much for all your help --- really appreciate it. It's OK, be glad your not trying to get support for some closed source crap at Friday afternoon 16.00 :-) Cheers, Stas -- A nation that continues year after year to spend more money on military def= ense than on programs of social uplift is approaching spiritual doom. Martin Luther King, Jr. -- A nation that continues year after year to spend more money on military def= ense than on programs of social uplift is approaching spiritual doom. Martin Luther King, Jr. |
|
From: Stas Z <sta...@gm...> - 2005-09-23 14:10:00
|
---------- Forwarded message ---------- From: Greg Wilson <gvw...@cs...> Date: Sep 23, 2005 3:42 PM Subject: Re: libgmail.py To: Stas Z <sta...@gm...> > It looks like a local problem, do you have ssl support compiled into > the urllib2? I'm using the ActiveState Python installer on Windows, so I don't know. How would I find out? > Do you have ssl installed? Yup (Cygwin). > Are you on the same system as yesterday? Nope, working at home. Thanks very much for all your help --- really appreciate it. Greg -- A nation that continues year after year to spend more money on military def= ense than on programs of social uplift is approaching spiritual doom. Martin Luther King, Jr. |
|
From: Stas Z <sta...@gm...> - 2005-09-23 14:09:47
|
It might be of use for others too
Stas
---------- Forwarded message ----------
From: Greg Wilson <gvw...@cs...>
Date: Sep 23, 2005 3:13 PM
Subject: Re: libgmail.py
To: Stas Z <sta...@gm...>
Hi Stas,
Just downloaded a fresh version from the web, and I'm getting this:
gvwilson@foyle /cygdrive/c/temp/libgmail-0.1.3.1
$ python libgmail.py
Gmail account name: XXXXXXX
Password:
Please wait, logging in...
Traceback (most recent call last):
File "libgmail.py", line 1459, in ?
ga.login()
File "libgmail.py", line 324, in login
pageData =3D self._retrievePage(req)
File "libgmail.py", line 354, in _retrievePage
resp =3D urllib2.urlopen(req)
File "c:\Python23\lib\urllib2.py", line 129, in urlopen
return _opener.open(url, data)
File "c:\Python23\lib\urllib2.py", line 331, in open
'unknown_open', req)
File "c:\Python23\lib\urllib2.py", line 306, in _call_chain
result =3D func(*args)
File "c:\Python23\lib\urllib2.py", line 914, in unknown_open
raise URLError('unknown url type: %s' % type)
urllib2.URLError: <urlopen error unknown url type: https>
Thanks,
Greg
--
A nation that continues year after year to spend more money on military def=
ense
than on programs of social uplift is approaching spiritual doom.
Martin Luther King, Jr.
|
|
From: Stas Z <sta...@gm...> - 2005-09-23 13:06:12
|
On 9/22/05, Richard Jones <jo...@gm...> wrote:
> > I suspect because gmailfs interacts with the internal message threads
> > rather then
> > through an API, it gets into trouble because there are changes to these=
internal
> > class attributes.
[....]
> You are quite correct I shouldn't be messing with the internal class
> attributes, however I don't think this is the core problem here
> (although it doesn't help).
>
> If you look at the GmailSearchResult initialisation method below:
[...]
> except IndexError:
> print "Empty account"
[...]
> Based on the error message "Empty Account" you seem to be assuming
> that threadsInfo[0] will be an illegal index only when the account is
> empty. In fact there appears to be a much more common reason for
> threadsInfo to be empty, this seems to occur (based on my limited
> testing) when the query returns no results.
Your right the message is wrong it should say "Empty thread"
[...]
> attributes, I couldn't find an API supported way of directly indexing
> particular thread and message numbers, please tell me if I'm missing
> something).
Well I guess if you using libgmail in such a way as you do in gmailfs
your better of with a abstraction layer that can function as a interface
to libgmail.
My proposal to you as your a "libgmail-poweruser" is this;
If you describe which methods you need then we will provide a object
that act as a interface between gmailfs and libgmail.
We will maintain this class so that any change we make to libgmail
will also be changed in the interface class.
We will put it into a module of it's own so that it doesn't affect the 'nor=
mal'
libgmail usage.
For example:
You want to know how many messages there are in a thread.
So you want to do something like:
from FsInter import FsInter # This is the abstraction class
ga is FsInter.GMAccount("name","pass")
ga.login()
thread =3D ga.getMessages.......
....
def getinodemsg():
......
......
return thread.NumberOf Messages()
Or something like that.
Then you don't have to care about our changes :-)
We will make sure that the abstraction class gets to the internals in
a proper way.
Stas
--
A nation that continues year after year to spend more money on military def=
ense
than on programs of social uplift is approaching spiritual doom.
Martin Luther King, Jr.
|
|
From: Richard J. <jo...@gm...> - 2005-09-23 02:58:05
|
On 9/22/05, Stas Z <sta...@gm...> wrote:
> On 9/21/05, Sebastien Delafond <sde...@gm...> wrote:
> > Unfortunately this doesn't fix gmailfs: I am still getting errors on
> First of all, I know nothing about gmailfs, but I see some trouble spots.
>
> [...]
> > ~ # sudo touch /mnt/test
> > Empty account
> > Traceback (most recent call last):
> > File "/usr/share/gmailfs/gmailfs.py", line 1094, in getinodemsg
> > return thread._messages[len(thread._messages)-1]
> > IndexError: list index out of range
> Just guessing here, but I suspect this is the GmailThread._messages attri=
bute.
> If so it's better not to use attributes directly but to use the API
> Further more if indeed GmailThread._messages is used, this class
> hasn't changed since
> libgmail version 0.1.0.
>
> [....]
> > And then listing it doesn't yield an exception, but something even
> > weirder:
> >
> > ~ # sudo ls /mnt/bar
> > Empty account
> Yet another result of accessing class attributes directly rather then
> through an API.
> It's part of a exception catch I added to test for empty message threads.
>
> I suspect because gmailfs interacts with the internal message threads
> rather then
> through an API, it gets into trouble because there are changes to these i=
nternal
> class attributes.
>
> >
> > Has there been an API change somewhere, among all those
> > bugfixes/security fixes ?
> Changes yes, to an API no.
>
> I hope richard can comment on this, because I don't know how gmailfs (ab)=
uses
> libgmail.
>
Hi Stas,
You are quite correct I shouldn't be messing with the internal class
attributes, however I don't think this is the core problem here
(although it doesn't help).
If you look at the GmailSearchResult initialisation method below:
class GmailSearchResult:
"""
"""
def __init__(self, account, search, threadsInfo):
"""
`threadsInfo` -- As returned from Gmail but unbunched.
"""
#print "\nthreadsInfo\n",threadsInfo
try:
if not type(threadsInfo[0]) is types.ListType:
threadsInfo =3D [threadsInfo]
except IndexError:
print "Empty account"
threadsInfo =3D [ ['']*13 ]
self._account =3D account
self.search =3D search # TODO: Turn into object + format nicely.
self._threads =3D []
#print "\nthreadInfo\n",pprint.pprint(threadsInfo)
####### debug code #########
## f =3D open('out.txt','w')
## pprint.pprint(threadsInfo,f,4)
## f.close()
#############################
for thread in threadsInfo:
self._threads.append(GmailThread(self, thread))
Based on the error message "Empty Account" you seem to be assuming
that threadsInfo[0] will be an illegal index only when the account is
empty. In fact there appears to be a much more common reason for
threadsInfo to be empty, this seems to occur (based on my limited
testing) when the query returns no results. By catching the error in
the way you are doing and filling threadsInfo with some value to
prevent it being empty you are causing len on a GmailSearchResult to
return 1, when really there were no results. The gmailfs errors occur
when after checking the len and finding it is one I then grab some
stuff on the assumption that there are results when really there are
none. If you can make the len return 0 when there were no results
(which seems to make sense) then the other gmailfs problems should go
away (although I am still being silly and accessing internal
attributes, I couldn't find an API supported way of directly indexing
particular thread and message numbers, please tell me if I'm missing
something).
Regards,
Richard.
|
|
From: Stas Z <sta...@gm...> - 2005-09-22 18:30:46
|
Hello, We should think about the lockdown problem when using libgmail. I had this afternoon most of mine accounts locked down due to some heavy testing :-) Some ideas: Introduce a pause when fetching extened contacts, this also includes gettin= g the notes. Split 'getting messages' in 'get unread inbox messages' and 'get all inbox messages'. Seems to me that this would be more usefull then getting all the messages every time. Getting only the unread messages I mean. Create some sort of limit for the requesting of pages, so that after an amo= unt of request there's a pause. Let me know what you think of this. Stas -- A nation that continues year after year to spend more money on military def= ense than on programs of social uplift is approaching spiritual doom. Martin Luther King, Jr. |
1 message has been excluded from this view by a project administrator.
