[Gmailagent-devel] Re: Mylibgmail contacts initial observations

[Waseem D. <wd...@gm...>]

On Mon, 2005-05-30 at 10:11 +0200, Stas Z wrote:
> - Wouldn't it be better to rename Mylibgmail to GAlibgmail or
> something to make it clear it's a fork
> of the original libgmail. 
> (The original libgmail author doesn't respond to any of my mails, I
> will however sent him a patch of everything we did so far.)

Yeah, a better name certainly doesn't hurt. I will probably make the
changes you discuss below at some point in the near future, so perhaps
we should wait till then till sending the patch. Either way.

> - At line 720 (added dots to preserve indentation, I hope):
> for myTuple in addresses:
> .            # Each tuple has ~15 address entries
> .            for entry in myTuple:
> .                # Consider checking the length of entry before this?
> .                newGmailContact = GmailContact(entry[1], entry[2],
> entry[4], entry[5])
> .                contactList.append(newGmailContact)
> We could just wrap the whole entry slicing in a try/except block and
> replace entries with
> empty string on a exception ?
Yeah, or we could just check len(entry). Either way.

> - At line 740:
> .        # TODO: In the ideal world, we'd extract these specific
> .        # constants into a nice constants file 
> What prevents us from creating a perfect world ?
> (I mean a libgmail world of course ;-)
Not a bad idea. I think the libgmail author intended to do something
like that given his TODOs, so perhaps it's a good start.

> - At line 782:
> .       # TODO: Maybe make sure that this ID exists or something
> .        #       smart like that?
> Wrapping in a try/except block ?
> 
> - At line 799:
> # TODO: Ensure that this is really a GmailContact?
>  # Also, maybe this could lead to weird bad cache coherence?
> # Imaigne user A gets the contact list
> # Then user B, using gmail, deletes contact X and adds contact Y
> # which then gets contact X's id
> # Then, A tries to delete X using this, but deletes Y
> # by accident!
> # So it's a concern to do things strictly by ID like this
> # If we were smarter, we could fetch the contact list again
> # and compare fields, I suppose
> Isn't this important enough to fetch a new contacts list before removal ?
> Gmail isn't a database so we can't block anything but perhaps getting a new list
> is the second best.
Yeah, perhaps the best idea is to remove the
blindly-specify-an-id-delete function, make you specify a GmailContact,
and ensure that that GmailContact exists in Gmail-world before really
deleting it.

> - At line 842:
> def getContactById(self, id):
>         """
>         Returns the first contact in the
>         address book with the specified id.
>         Contact list *should* be unique by id
>         (unless gmail stops enforcing this) 
> Perhaps return every specified id, then let the user decide which he meant?
> (The same for the getContactbyEmail method)
Not a bad idea, though the only disadvantage is that we expect, like,
99% of the time, for the fields to be unique, so it'll be a bit of a
pain making the end-user access [0] every time, or something like that.

Maybe a special method that returns the lists, for all of these
functions (that way we can deal with the normal and worst cases
separately?)

> And then:
> # This is going to be O(n), which sort of sucks
> What do you mean by that?
You basically have to go through the whole list (well, half of the list
in the average case) to get the contact you want.
I can imagine a much more clever near-constant-time data structure that
hashes the contacts in some sort of hash table and retrieves them that
way, but I think probably that solution is not really worth it (since n
is going to be pretty small as it is -- address books aren't GIANT)

> BTW, Do you have any ideas or plans for the future of
> gmailagent/libgmail or is this a
> one time project for you ?
gmailagent, not so much -- GUIs don't particularly interest me a whole
lot. libgmail was fun, though. I'm not really clever enough to
reverse-engineer new functionality for it (at least, not  yet), but some
guys have an API in C# that apparently implements the entire thing
(which I consulted a bit in doing the contacts stuff), so there's always
room to implement the remainder of those features.

It might be cool to maintain some sort of "gmailagent-libgmail" if the
current guy continues to be unreachable... because projects written in
Python should also be able to use gmail just like anyone else.

For now, I'll probably just make the changes specified above, and we'll
see how much time I have on my hands after that :-)

-- Waseem