[Gmailagent-devel] Re: Re: libgmail bugfix release 0.1.3

[Richard J. <jo...@gm...>]

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.