gmailagent-devel

[Gmailagent-devel] Mylibgmail contacts initial observations

[Stas Z <sta...@gm...>]

Hi Waseem.

I have some questions.

- Wouldn't it be better to rename Mylibgmail to GAlibgmail or
something to make it clear it's a fork
of the original libgmail.=20
(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.)

- 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 =3D 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 ?

- At line 740:
.        # TODO: In the ideal world, we'd extract these specific
.        # constants into a nice constants file=20
What prevents us from creating a perfect world ?
(I mean a libgmail world of course ;-)

- 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.

- 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)=20
Perhaps return every specified id, then let the user decide which he meant?
(The same for the getContactbyEmail method)

And then:
# This is going to be O(n), which sort of sucks
What do you mean by that?


Now I'm going to play with the contacts toy :-)

BTW, Do you have any ideas or plans for the future of
gmailagent/libgmail or is this a
one time project for you ?

Stas

--=20
"Everything that is really great and inspiring is created by the individual
 who can labor in freedom."
-Albert Einstein

[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

[Gmailagent-devel] Re: Mylibgmail contacts initial observations

[Stas Z <sta...@gm...>]

On 5/31/05, Waseem Daher <wd...@gm...> wrote:
> 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.)
>=20
> 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.
Hmm, I already send him a patch, no respond so I assume libgmail is
dead, Long Live libgmail :-)
Perhaps we should just call it 'libgmail2'.

[...]

> >         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 me=
ant?
> > (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.
>=20
> 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?)
Agreed.
=20
> > 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)
Indeed, it might be overkill.
=20
> > 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.
>=20
> 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.
We just could set up a separate CVS module as part of gmailagent.
So gmailagent would become the home of gmailagent-qt, gmailagent-gtk
(I'm planning a gtk
port) and libgmail2.
I will look around if there are other projects that use libgmail and
try to contact them about our
forking.

> 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 :-)
You finished your semester so a real socially dysfunctional hacker
should have time enough now ;-)

Stas

--=20
"Everything that is really great and inspiring is created by the individual
 who can labor in freedom."
-Albert Einstein

[Gmailagent-devel] Re: Mylibgmail contacts initial observations

[Waseem S. D. <wd...@MI...>]

On Tue, 2005-05-31 at 19:47 +0200, Stas Z wrote:
> We just could set up a separate CVS module as part of gmailagent.
> So gmailagent would become the home of gmailagent-qt, gmailagent-gtk
> (I'm planning a gtk
> port) and libgmail2.
> I will look around if there are other projects that use libgmail and
> try to contact them about our
> forking.

If you could do that, that'd be great.

- W

[Gmailagent-devel] Re: Mylibgmail contacts initial observations

[Waseem S. D. <wd...@MI...>]

On Wed, 2005-06-01 at 12:26 +0200, Stas Z wrote:
> I will setup a seperate CVS module for libgmail, but I'm not so sure anymore
> about contacting other projects about our fork, it seems a bit to fanatic to
> contact other projects and tell them " hey use our libgmail, the other
> sucks" ;-)
> 
> I mean, perhaps it's better to see how it goes, besides I'm only could find
> two serious projects which uses libgmail.

libgmail2 sounds like a reasonable name for our fork.

I don't think it's a terrible idea to contact these other libgmail users
about our new version, especially if they want to use contacts support
and all that. 

To be honest, if the original libgmail author eventually responds, I'd
have no problem with just giving him our patch and having him continue
to maintain a working libgmail, but until that happens, I think we have
an obligation of sorts to let people know about our more-featureful one.
Though perhaps we should hold off on the notification till I make those
changes (i.e. until we have a firm API for contacts).

- W

[Gmailagent-devel] Re: Mylibgmail contacts initial observations

[Stas Z <sta...@gm...>]

On 6/1/05, Waseem S. Daher <wd...@mi...> wrote:
> On Wed, 2005-06-01 at 12:26 +0200, Stas Z wrote:
> > I will setup a seperate CVS module for libgmail, but I'm not so sure an=
ymore
> > about contacting other projects about our fork, it seems a bit to fanat=
ic to
> > contact other projects and tell them " hey use our libgmail, the other
> > sucks" ;-)
> >
> > I mean, perhaps it's better to see how it goes, besides I'm only could =
find
> > two serious projects which uses libgmail.
>=20
> libgmail2 sounds like a reasonable name for our fork.
libgmail2 it is. The CVS module will be called 'GA-libgmail2'.
(it's available from this moment, Mylibgmail.py is renamed libgmail2.py)

> I don't think it's a terrible idea to contact these other libgmail users
> about our new version, especially if they want to use contacts support
> and all that.
>=20
> To be honest, if the original libgmail author eventually responds, I'd
> have no problem with just giving him our patch and having him continue
> to maintain a working libgmail, but until that happens, I think we have
> an obligation of sorts to let people know about our more-featureful one.
> Though perhaps we should hold off on the notification till I make those
> changes (i.e. until we have a firm API for contacts).
Agreed, we wait until libgmail2 is a bit more mature.
I'll get hacking at the contacts stuff to replace the current local address=
book
with a remote gmail contacts one.
It would be nice to see how the contacts support works in a real world
application.

Stas


--=20
"Everything that is really great and inspiring is created by the individual
 who can labor in freedom."
-Albert Einstein

[Gmailagent-devel] Re: Mylibgmail contacts initial observations

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

All of the below-requested features are now done and checked into CVS
(with an awesome test suite, too! It takes about a minute to run though,
and may need Python 2.4, since apparently 2.3's unittest module doesn't
have assertTrue? You can probably hack it together by replacing
assertTrue( with assertEquals(True, )

The one thing that remains undone is to extract out some of the URLs
into either the top of the file or the constants file, as the original
libgmail author seems to have intended (and as they do in the Johnvey C#
API). This is a pretty trivial step.

I think the test suite is *reasonably* complete -- it did help me find a
bunch of bugs, anyway. Steve Howell would be so proud of me :-P

- Waseem

On Mon, 2005-05-30 at 10:11 +0200, Stas Z wrote:
> Hi Waseem.
> 
> I have some questions.
> 
> - 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.)
> 
> - 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 ?
> 
> - 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 ;-)
> 
> - 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.
> 
> - 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)
> 
> And then:
> # This is going to be O(n), which sort of sucks
> What do you mean by that?
> 
> 
> Now I'm going to play with the contacts toy :-)
> 
> BTW, Do you have any ideas or plans for the future of
> gmailagent/libgmail or is this a
> one time project for you ?
> 
> Stas
> 

[Gmailagent-devel] Re: Mylibgmail contacts initial observations

[Stas Z <sta...@gm...>]

On 6/2/05, Waseem Daher <wd...@gm...> wrote:
> All of the below-requested features are now done and checked into CVS
> (with an awesome test suite, too! It takes about a minute to run though,
> and may need Python 2.4, since apparently 2.3's unittest module doesn't
> have assertTrue? You can probably hack it together by replacing
> assertTrue( with assertEquals(True, )
Great, the recursion is a nice approach, but I personally don't much
like recursion when I use recursion ;-)

> The one thing that remains undone is to extract out some of the URLs
> into either the top of the file or the constants file, as the original
> libgmail author seems to have intended (and as they do in the Johnvey C#
> API). This is a pretty trivial step.
Ok.

> I think the test suite is *reasonably* complete -- it did help me find a
> bunch of bugs, anyway. Steve Howell would be so proud of me :-P
Hmm, it's also *reasonably* tricky as you remove the contents of the contac=
ts !
Why don't you add test entries and work with those, I think deleting
the contacts is a
bad thing. But for the rest it's a nice testsuite indeed.
It's perhaps an better idea that we set up a gmail account for testing purp=
oses.

I like that so much I've just had set it up :-)

(Details about this account are send to Waseem personally)

We should use this account for testing purposes.

Stas

--=20
"Everything that is really great and inspiring is created by the individual
 who can labor in freedom."
-Albert Einstein