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: Waseem S. D. <wd...@MI...> - 2005-06-10 17:06:43
|
On Fri, 10 Jun 2005, Stas Z wrote: > After about 16 hours of hacking I came to the conclusion that my approach of > a local contacts file in conjunction with the online contacts is > terrible to maintain :-( I definitely don't disagree here. Maintaining some sort of coherency between two copies of data is always icky. > RFC: > My idea is to create a separate GUI as a local frontend to the whole > Gmail contacts > framework, including editing, adding and removal. When there's support > for the export > of the contacts into other formats, like discussed in a prior post, I > will include that also. > This frontend will import the contacts, the user can do his thing and > saves the contacts > to disk. (That should perhaps also be the default action when the user > closes the app) Maybe this is the part I don't understand. Would this frontend run only once, on initial GmailAgent start? Or would it start at the beginning of each session, constantly getting the revised contacts list? I guess the only reason I don't like the idea is that you won't always have the most up-to-date Gmail contacts. But I guess it's hard to design an elegant solution to do that ... so I suppose this is a reasonable second best. Though there should be an option to invoke the updater yourself. What about not maintaining your own list at all, though, and just reading from Gmail every time you want to do a contacts transaction? The downside there is you have to be online and it might consume a bit of bandwidth. In short: I think it is certainly a reasonable approach. I intend to do the vCard export at some point in the near future (perhaps this weekend). - W |
|
From: Stas Z <sta...@gm...> - 2005-06-10 09:08:53
|
Hi, I'm currently hacking GmailAgent to add the new contacts support. After about 16 hours of hacking I came to the conclusion that my approach o= f a local contacts file in conjunction with the online contacts is terrible to maintain :-( It's to difficult to get the the two in sync under all circumstances and it breaks my beautiful designed GA app ;-) So I will start over with a new approach :-) RFC: My idea is to create a separate GUI as a local frontend to the whole Gmail contacts framework, including editing, adding and removal. When there's support for the export of the contacts into other formats, like discussed in a prior post, I will include that also. This frontend will import the contacts, the user can do his thing and saves the contacts to disk. (That should perhaps also be the default action when the user closes the app) So GA for example will just use the contacts file that is saved to disk by the contacts frontend. When there's no contacts file known to GA it will suggest ask the user if the contacts frontend should be started. The benefits of a separate tool would be that it can also be used as a tool just to synchronize ones local and online contacts as well as provide a contacts application for other projects besides GA. The frontend will be developed with the QT tool kit using a MVC pattern to make it easier to develop other GUI's using wxwindows, GTK++ etc. Stas --=20 "Everything that is really great and inspiring is created by the individual who can labor in freedom." -Albert Einstein |
|
From: Stas Z <sta...@gm...> - 2005-06-07 05:04:04
|
On 6/7/05, Waseem S. Daher <wd...@mi...> wrote: > I like em both. I'll probably do #2 before #1, but even then, not for a > little while --=20 just getting settled in here in Seattle, and I've got to > get Internet working in my room at some point. >=20 Ah, you at your summer job :-) Hows Seattle?=20 Stas --=20 "Everything that is really great and inspiring is created by the individual who can labor in freedom." -Albert Einstein |
|
From: Waseem S. D. <wd...@MI...> - 2005-06-07 03:30:27
|
I like em both. I'll probably do #2 before #1, but even then, not for a little while -- just getting settled in here in Seattle, and I've got to get Internet working in my room at some point. - W On Mon, 2005-06-06 at 09:48 +0200, Stas Z wrote: > Hi Waseem. > > I would like to suggest two possible features for libgmail2. > > 1. Messages, with multiple attachments, bigger then 10 MB would be > divided into multiple > messages. > So for instance a message body with 5 attachments each 3 MB would > become two messages > with the same body text with 2 and 3 attachments each. > The subject line would be changed for each message, perhaps appended > "Part #1" and "Part #2" or something like that. > > 2. The possibility to export the Gmail contacts to an other format so > that they can be > imported by other mail clients. Perhaps exporting to VCard format? > (RFC 2426: http://www.faqs.org/rfcs/rfc2426.html ) > > > Stas > |
|
From: Stas Z <sta...@gm...> - 2005-06-06 07:48:14
|
Hi Waseem. I would like to suggest two possible features for libgmail2. 1. Messages, with multiple attachments, bigger then 10 MB would be divided into multiple messages. So for instance a message body with 5 attachments each 3 MB would become two messages with the same body text with 2 and 3 attachments each. The subject line would be changed for each message, perhaps appended "Part #1" and "Part #2" or something like that. 2. The possibility to export the Gmail contacts to an other format so that they can be imported by other mail clients. Perhaps exporting to VCard format? (RFC 2426: http://www.faqs.org/rfcs/rfc2426.html ) Stas --=20 "Everything that is really great and inspiring is created by the individual who can labor in freedom." -Albert Einstein |
|
From: Waseem S. D. <wd...@MI...> - 2005-06-04 16:05:14
|
On Sat, 2005-06-04 at 16:31 +0200, Stas Z wrote: > Indeed. > I'm thinking at which level we could implement some sort of emergency backup > ideally it would be in libgmail2, hold on don't flame me, It's just a > random thought I have :-) > > For now I will let GA take care of it. :-) It really could go either way. My only concern about putting it in libgmail2 is that some applications just don't need it. Imagine I am writing a program that is just going to download your gmail address book and add the entries into Evolution (or something like this). I don't need emergency recovery because I don't delete any contacts -- so why waste my time and space doing it? Though... it's true that some applications will probably want it, and for that reason maybe we want to make a flag in libgmail2 that is like "do emergency backups" or whatever. I'm willing to say it's a feature if we get to it, but I think it should probably be lower on the priority list than adding more functionality. - W |
|
From: Stas Z <sta...@gm...> - 2005-06-04 14:32:53
|
On 6/4/05, Waseem S. Daher <wd...@mi...> wrote: > > > The (almost) worst thing I can imagine is a email from a GA user that t= ells me: > > " GA erased my contacts list, and now I hate you forever!!" > > > > It would be nice to reply: > > "You stupid MS lover, your contacts are save and sound on your disk" > > :-) >=20 > Better safe than sorry. You've convinced me :). Now deciding *when* to > save the contacts is another story, but that's something that each > application will probably have to figure out. Indeed. I'm thinking at which level we could implement some sort of emergency backu= p ideally it would be in libgmail2, hold on don't flame me, It's just a random thought I have :-) For now I will let GA take care of it. Stas --=20 "Everything that is really great and inspiring is created by the individual who can labor in freedom." -Albert Einstein |
|
From: Waseem S. D. <wd...@MI...> - 2005-06-04 03:09:33
|
On Fri, 2005-06-03 at 19:08 +0200, Stas Z wrote: > The thing that keeps bothering me about the whole contacts issue is > that there's a potential > problem with removing/adding contacts. What happens when the > application crashes in the > middle of a libgmail2 action? > You could end up with a (partly) cleared contacts list online, a > contacts list in memory > (contacts = ga.getContacts().getAllContacts()) and a application > that's crashed. Yeah, there's no way to guarantee the atomicity of our actions on your gmail account, so this is definitely a valid point. > What can you do to save the users data? > write them to disk before the Python VM exits. > > I really love apps that saves my work when crashing. > I don't mind an app that screws up but I hate a developer that doesn't saves my > data on a screw up. :-/ > > The (almost) worst thing I can imagine is a email from a GA user that tells me: > " GA erased my contacts list, and now I hate you forever!!" > > It would be nice to reply: > "You stupid MS lover, your contacts are save and sound on your disk" > :-) Better safe than sorry. You've convinced me :). Now deciding *when* to save the contacts is another story, but that's something that each application will probably have to figure out. - W |
|
From: Stas Z <sta...@gm...> - 2005-06-03 17:09:02
|
On 6/3/05, Waseem S. Daher <wd...@mi...> wrote:
> Interesting approach.
> I probably don't understand where you're going with this though, because
> I wonder why you'd want to save state internally at all?
Well the function is called from here:
try:
contacts =3D ga.getContacts().getAllContacts()
# Just to test save_contacts without having to raise an exception
save_contacts(contacts)
for contact in contacts:
if GM_DEBUG: logging.debug("Removing contact", contact)
ga.removeContact(contact)
except Exception,info:
logging.critical(str(info))
if contacts:
save_contacts(contacts)
The potential problem arises when an exception is raised after the
contacts are removed but
before the new ones are added. (More arguments below)
> Whatever lives
> in Gmail should be the definitive version of the contacts, right? So why
> would we ever need to read from them locally?
In GmailAgent I keep a local address file in the users home dir which
is a copy of the Gmail
contacts online.
GA uses this local address file to prevent logins into Gmail when it's
not really needed.
My idea was that GA should use this local file and when ever the user
changes something
it would be added/changed in the local file. Then when the 'editor' is
closed or opened the user is asked if he wants to import/export a
'fresh' contacts list from Gmail.
When importing/exporting the online list is merged with the online version.
The Gmail contacts is cleared and updated again with all the contacts
from the local file.
I hope this makes any sense, I'm in the middle of implementing it, so
I myself don't know how
the finished contacts framework will look like :-)
You could checkout GA-main and start GmailAgent.py from a xterm and
hit a few address
related buttons, it would be clear what's happening.
> Though I guess it can't hurt.
The thing that keeps bothering me about the whole contacts issue is
that there's a potential
problem with removing/adding contacts. What happens when the
application crashes in the
middle of a libgmail2 action?
You could end up with a (partly) cleared contacts list online, a
contacts list in memory
(contacts =3D ga.getContacts().getAllContacts()) and a application
that's crashed.
What can you do to save the users data?=20
write them to disk before the Python VM exits.=20
I really love apps that saves my work when crashing.
I don't mind an app that screws up but I hate a developer that doesn't save=
s my
data on a screw up. :-/
The (almost) worst thing I can imagine is a email from a GA user that tells=
me:
" GA erased my contacts list, and now I hate you forever!!"
It would be nice to reply:
"You stupid MS lover, your contacts are save and sound on your disk"
:-)
Stas
--=20
"Everything that is really great and inspiring is created by the individual
who can labor in freedom."
-Albert Einstein
|
|
From: Waseem S. D. <wd...@MI...> - 2005-06-03 15:57:10
|
Interesting approach.
I probably don't understand where you're going with this though, because
I wonder why you'd want to save state internally at all? Whatever lives
in Gmail should be the definitive version of the contacts, right? So why
would we ever need to read from them locally?
Though I guess it can't hurt.
- W
On Fri, 2005-06-03 at 17:32 +0200, Stas Z wrote:
> I was hacking gmailagent to add a 'save contacts when something goes
> wrong' function.
> It occurs to me that libgmail2 does very little to save the contacts
> in case or errors.
>
> I just paste the stuff I come up with for gmailagent.
> (It can be found in Gmail.py)
>
> Stas
>
> def save_contacts(contacts):
> """Save the contact in case of an error. This is an attempt to prevent
> data loss in case of an error when interacting with Gmail contacts."""
> try:
> f = open(os.path.expanduser('~/.GmailContacts.pickle'),'w')
> pickle.dump(contacts,f)
> ## XXX TODO: some way to load the pickled object and restore it
> except Exception,info:
> text = "Attempt to pickle the contacts %s" % str(info)
> logging.critical(text)
> f.close()
> try:
> f =open(os.path.expanduser('~/.GmailContacts.txt'),'w')
> text = "#An error occured in GmailAgent and these contacts are
> saved\n"+\
> "#to this file in an attempt to save them\n"+\
> "#A contact is saved as follows:\n"+\
> "#GmailID Name email notes\n"
> f.write(text)
> for con in contacts:
> name,email,notes,id =
> con.getName(),con.getEmail(),con.getNotes(),con.getId()
> f.write("%s %s %s %s\n" % (con.getId(),\
> con.getName(),\
> con.getEmail(),\
> con.getNotes()))
> f.close()
> except Exception,info:
> logging.critical(str(info))
> return str(info)
>
>
|
|
From: Stas Z <sta...@gm...> - 2005-06-03 15:32:36
|
I was hacking gmailagent to add a 'save contacts when something goes
wrong' function.
It occurs to me that libgmail2 does very little to save the contacts
in case or errors.
I just paste the stuff I come up with for gmailagent.
(It can be found in Gmail.py)
Stas
def save_contacts(contacts):
"""Save the contact in case of an error. This is an attempt to prevent
data loss in case of an error when interacting with Gmail contacts."""
try:
f =3D open(os.path.expanduser('~/.GmailContacts.pickle'),'w')
pickle.dump(contacts,f)
## XXX TODO: some way to load the pickled object and restore it
except Exception,info:
text =3D "Attempt to pickle the contacts %s" % str(info)
logging.critical(text)
f.close()
try:
f =3Dopen(os.path.expanduser('~/.GmailContacts.txt'),'w')
text =3D "#An error occured in GmailAgent and these contacts are
saved\n"+\
"#to this file in an attempt to save them\n"+\
"#A contact is saved as follows:\n"+\
"#GmailID Name email notes\n"
f.write(text)
for con in contacts:
name,email,notes,id =3D
con.getName(),con.getEmail(),con.getNotes(),con.getId()
f.write("%s %s %s %s\n" % (con.getId(),\
con.getName(),\
con.getEmail(),\
con.getNotes()))
f.close()
except Exception,info:
logging.critical(str(info))
return str(info)
=20
--=20
"Everything that is really great and inspiring is created by the individual
who can labor in freedom."
-Albert Einstein
|
|
From: Stas Z <sta...@gm...> - 2005-06-03 06:56:56
|
Waseem, Creating a single Python package is very easy :-) http://www.python.org/doc/2.4.1/dist/simple-example.html This is probably all you need, assuming your package will consist of libgmail2.py and constants.py. Additional info: The above tutorial uses a call like 'python setup.py sdist' to create a tgz, this can be usefull but in my expirience it's to limited because you probably want to include some docs like the GPL, README etc. What I do is that I skip the 'sdist' call and just manually create a tarball/zip package. The 'setup.py' script is the one that does all the install work 'sdist' is just a shortcut to create a tarball. Be aware that when you test your package you first *must* remove any old files from a former installed package. This must be done by hand to prevent Python importing an wrong module. (The modules are installed in /usr/lib/python-2.4/site-packages) Good luck :-) Stas Example of a simple Python package: 'Assetml', something I created for the ofset project, http://www.ofset.org/assetml The source code, including the setup.py can be seen here, http://cvs.sourceforge.net/viewcvs.py/ofset/assetml/pyassetml/ --=20 "Everything that is really great and inspiring is created by the individual who can labor in freedom." -Albert Einstein |
|
From: Waseem S. D. <wd...@MI...> - 2005-06-02 20:20:10
|
On Thu, 2005-06-02 at 21:20 +0200, Stas Z wrote: > > > BTW, we should think about making libgmail2 a seperate package, not a > > > seperate project, but > > > a package which is part of the gmailagent project. > > > It would be easier for another project to use libgmail2. > > Definitely. > Well, you have admin rights so you can take all the necessary actions :-) > Do you have experience with creating a Python package? Nope :-) - W |
|
From: Stas Z <sta...@gm...> - 2005-06-02 19:20:58
|
On 6/2/05, Waseem S. Daher <wd...@mi...> wrote: > > BTW, we should think about making libgmail2 a seperate package, not a > > seperate project, but > > a package which is part of the gmailagent project. > > It would be easier for another project to use libgmail2. > Definitely. Well, you have admin rights so you can take all the necessary actions :-) Do you have experience with creating a Python package? > > BTW, are you on the gmailagent-devel list? It would be better to > > discuss devel issues there. > Yep, I've been cc:ing my mail there, and I'm a member. Ok, that reminds me I must change the 'reply to' header from the devel list so that our replies go to the list automatically. =20 BTW, I have dumped the address book in gmailagent and started implementing one based on our new contacts feature in conjunction with a local contacts file. Your additions to libgmail2 work perfect, I have great fun hacking gmailagent :-) Stas --=20 "Everything that is really great and inspiring is created by the individual who can labor in freedom." -Albert Einstein |
|
From: Waseem S. D. <wd...@MI...> - 2005-06-02 18:39:35
|
On Thu, 2005-06-02 at 16:44 +0200, Stas Z wrote: > I have no problem with the tests, they all pass. > I'm using the test account of course, you've received the mails about > that I hope? Yep, I made one as well. > I always want to make sure the test I use are executed in order, no > matter if order matters > or not. I think that a test suite should be as controlled as possible, > so I want my tests done > in a fixed order. > But your the libgmail2 maintainer so it's your call :-) Seems reasonable > BTW, we should think about making libgmail2 a seperate package, not a > seperate project, but > a package which is part of the gmailagent project. > It would be easier for another project to use libgmail2. Definitely. > > Thought: I can understand why you don't like the > > delete-contacts-every-time approach, but the advantage there is that we > > start with a clean slate every time, and we don't need to worry about > > maybe test suites that only half-ran, etc., before. This way you can run > > the tests on any gmail account, not one you have to prepare by hand > > first. > You can be serious about that, when I run the test suite against my > gmail account all > my contacts will be gone ! > That's why I set up another gmail account for us to use. I agree that you wouldn't want to do it on any gmail account, I just dislike the idea of having to prime the account by putting it into some special state before we can use it -- which makes things more difficult if we start to make more advanced tests, as well. Either way is fine really, I just think this approach is simpler from a testing standpoint (fewer variables). > BTW, are you on the gmailagent-devel list? It would be better to > discuss devel issues there. Yep, I've been cc:ing my mail there, and I'm a member. - Waseem |
|
From: Waseem S. D. <wd...@MI...> - 2005-06-02 14:18:26
|
I've incorporated basically all of the changes of testlibgmail2_stas.py into testlibgmail2, with basically one exception: I kept my original class name -- I was envisioning a separate class for each "part" of libgmail that we wanted to test, and didn't really understand your name. I really do like the added verbosity, though. That's really what I was looking for -- just wasn't sure how to make it happen, though. However, my 25-contacts test seems to be failing this morning, where it worked fine last night... which makes me unhappy. I'll look into that later, I guess. One question and one thought, though: Question: Why the numbers after test (like test3_addContacts, or whatever)? I previously thought that the tests needed to run in order - this isn't the case anymore, so if those numbers are there to ensure order, we may as well remove them. Thought: I can understand why you don't like the delete-contacts-every-time approach, but the advantage there is that we start with a clean slate every time, and we don't need to worry about maybe test suites that only half-ran, etc., before. This way you can run the tests on any gmail account, not one you have to prepare by hand first. - W |
|
From: Stas Z <sta...@gm...> - 2005-06-02 10:17:07
|
Hi Waseem I added testlibgmail2_stas.py to CVS/GA-libgmail2. It's basically your testsuite but refactored a bit to reflect my views on a test suite. I *don't* think your testsuite lacks things or is in need of refactoring, that's why I made a seperate module. IMHO, it's better to call the 'TestSuite' method on unittest instead of 'main' and that some extra messages in case of a 'fail' greatly improve the readability when som= e of the test fail. Just look at 'testlibgmail2_stas.py', it's easier then I'm trying to explain it here :-) Again, there's nothing wrong with your testsuite, I'm only showing my appr= oach. Stas --=20 "Everything that is really great and inspiring is created by the individual who can labor in freedom." -Albert Einstein |
|
From: Stas Z <sta...@gm...> - 2005-06-02 08:37:15
|
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 |
|
From: Waseem D. <wd...@gm...> - 2005-06-01 23:47:21
|
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 > |
|
From: Stas Z <sta...@gm...> - 2005-06-01 18:32:26
|
One of the things I found in my TODO list :-) """When a message is bigger then 10 MB in total split it in two or more parts. (Gmail allows up to 10MB each) Perhaps copy the first message and add 'part #' to the subject line ? """ Stas =20 --=20 "Everything that is really great and inspiring is created by the individual who can labor in freedom." -Albert Einstein |
|
From: Stas Z <sta...@gm...> - 2005-06-01 14:59:13
|
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 |
|
From: Waseem S. D. <wd...@MI...> - 2005-06-01 14:38:07
|
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 |
|
From: Stas Z <sta...@gm...> - 2005-06-01 10:21:19
|
Waseem, and anyone who's reading this. I want to suggest that we change the name of the libgmail library used by gmailagent to 'libgmail2' to make it clear it's a fork. This library will also get a CVS module of it's own in the gmailagent CVS t= ree. As the current gmailagent CVS module is called 'GA-main' I guess we could c= all the CVS module for libgmail 'GA-libgmail2' or whatever library name we choo= se. So, what should we call the fork of libgmail ? Stas=20 --=20 "Everything that is really great and inspiring is created by the individual who can labor in freedom." -Albert Einstein |
|
From: Waseem S. D. <wd...@MI...> - 2005-05-31 19:09:49
|
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 |
|
From: Stas Z <sta...@gm...> - 2005-05-31 17:47:28
|
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 |
1 message has been excluded from this view by a project administrator.
