You can subscribe to this list here.
2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(7) |
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
|
Feb
|
Mar
(5) |
Apr
|
May
(3) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(3) |
Nov
|
Dec
|
2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2006 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(3) |
Nov
|
Dec
|
2008 |
Jan
|
Feb
|
Mar
(4) |
Apr
(30) |
May
|
Jun
(6) |
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(3) |
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
(12) |
2010 |
Jan
|
Feb
|
Mar
(2) |
Apr
(9) |
May
(5) |
Jun
|
Jul
(21) |
Aug
(7) |
Sep
(5) |
Oct
|
Nov
|
Dec
|
From: kay <ka...@gm...> - 2010-09-15 01:28:55
|
OK, I will try to test it. --Kay 2010/9/15 Siddhesh Poyarekar <sid...@gm...> > Hi, > > I started ayttm with the new libyahoo2 build installed (without > rebuilding against it) and it crashed on me. Initial analysis suggests > that there is an ABI breakage, primarily due to changes in the > callback struct. I guess the main reason is due to the chat room > callback functions being put in the middle of the struct rather than > at the end of it. I'll have a closer look at this later when I have > more time. Can someone else (Kay?) also test this and if possible > provide patches to fix this breakage? The aim is to have applications > running without having to rebuild them against the latest libyahoo2 in > trunk. There is really no way we can do a release with this broken. > > -- > Siddhesh Poyarekar > http://siddhesh.in > > > ------------------------------------------------------------------------------ > Start uncovering the many advantages of virtual appliances > and start using them to simplify application deployment and > accelerate your shift to cloud computing. > http://p.sf.net/sfu/novell-sfdev2dev > _______________________________________________ > Libyahoo2-devel mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libyahoo2-devel > |
From: Siddhesh P. <sid...@gm...> - 2010-09-14 19:06:49
|
Hi, I started ayttm with the new libyahoo2 build installed (without rebuilding against it) and it crashed on me. Initial analysis suggests that there is an ABI breakage, primarily due to changes in the callback struct. I guess the main reason is due to the chat room callback functions being put in the middle of the struct rather than at the end of it. I'll have a closer look at this later when I have more time. Can someone else (Kay?) also test this and if possible provide patches to fix this breakage? The aim is to have applications running without having to rebuild them against the latest libyahoo2 in trunk. There is really no way we can do a release with this broken. -- Siddhesh Poyarekar http://siddhesh.in |
From: Siddhesh P. <sid...@gm...> - 2010-09-12 07:25:17
|
On Sun, Sep 12, 2010 at 12:02 PM, Tri S. <st...@gm...> wrote: > Dependency on SSL library is needed too for optionally building the > sample clients. May be someone can add this conditionals to our > configure script? > Yes, if the SSL library is not available, it should simply not build the sample clients. Alternatively, disabling the sample client should also disable this check. I was also thinking of installing the sample client sources in $docdir/examples. Does that sound like a good idea? It will provide a good starter for people who get libyahoo2 from distribution packages and not as upstream sources here. -- Siddhesh Poyarekar http://siddhesh.in |
From: Tri S. <st...@gm...> - 2010-09-12 06:33:04
|
Dependency on SSL library is needed too for optionally building the sample clients. May be someone can add this conditionals to our configure script? On 9/12/10, Siddhesh Poyarekar <sid...@gm...> wrote: > Hi, > > I have now documented the libyahoo2 code using doxygen style comments > and also added support in the build tools to get the docs to build > during compilation. Could someone please review the generated > documentation for technical accuracy, typos, laziness, etc.? Future > release will also involve publishing this documentation on the > website. > > Packagers will have to add an additional build dependency as doxygen > if they want to include the API documentation in their packages. The > documents are currently generated in man, html and latex format. > > -- > Siddhesh Poyarekar > http://siddhesh.in > > ------------------------------------------------------------------------------ > Start uncovering the many advantages of virtual appliances > and start using them to simplify application deployment and > accelerate your shift to cloud computing > http://p.sf.net/sfu/novell-sfdev2dev > _______________________________________________ > Libyahoo2-devel mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libyahoo2-devel > |
From: Siddhesh P. <sid...@gm...> - 2010-09-12 05:16:26
|
Hi, I have now documented the libyahoo2 code using doxygen style comments and also added support in the build tools to get the docs to build during compilation. Could someone please review the generated documentation for technical accuracy, typos, laziness, etc.? Future release will also involve publishing this documentation on the website. Packagers will have to add an additional build dependency as doxygen if they want to include the API documentation in their packages. The documents are currently generated in man, html and latex format. -- Siddhesh Poyarekar http://siddhesh.in |
From: Siddhesh P. <sid...@gm...> - 2010-08-30 20:07:03
|
On Sun, Aug 22, 2010 at 7:12 PM, Wilmer van der Gaast <wi...@ga...> wrote: > Hello, > > It seems to me like yahoo_process_buddyadd() makes wrong assumptions > about the status field. > Sorry, I completely forgot about this. I've pushed in your changes, thanks for the patch. -- Siddhesh Poyarekar http://siddhesh.in |
From: Wilmer v. d. G. <wi...@ga...> - 2010-08-22 14:06:05
|
Hello, It seems to me like yahoo_process_buddyadd() makes wrong assumptions about the status field. I had issues with BitlBee seeing "ghosts" online. It looks like the cause is in the handling of this status field. My comments: /* BitlBee: This seems to be wrong in my experience. I think: status = 0: Success status = 2: Already on list status = 3: Doesn't exist status = 42: Invalid handle (possibly banned/reserved, I get it for handles like joe or jjjjjj) Haven't seen others yet. But whenever the add is successful, there will be a separate "went online" packet when the auth. request is accepted. Couldn't find any test account that doesn't require auth. unfortunately (if there is even such a thing?) */ I just took out that code, but may be missing the case of people who don't require auth requests (gain, no clue of that even exists on YMSG). I also added a call to got_buddies since I let my IM modules ACK if an add was successful as some layer of "error checking". The full change is here: http://bugs.bitlbee.org/bitlbee/changeset/devel%2C670 Wilmer. -- +-------- .''`. - -- ---+ + - -- --- ---- ----- ------+ | wilmer : :' : gaast.net | | OSS Programmer www.bitlbee.org | | lintux `. `~' debian.org | | Full-time geek wilmer.gaast.net | +--- -- - ` ---------------+ +------ ----- ---- --- -- - + |
From: kay <ka...@gm...> - 2010-08-14 01:15:12
|
My username at SourceForge.net is kay21s Thanks =) --Kay 2010/8/14 Siddhesh Poyarekar <sid...@gm...> > Hi, > > Yahoo chat room support is now in trunk. Many thanks to Kai (Kay) > Zhang for this effort, which he made as part of his Fedora Summer > Coding project. The code obviously needs some review and testing, so > those interested, please feel free to pitch in. > > I expected git-svn to commit the patchset along with the history in > Kay's git repository, but unfortunately that did not happen. So those > who want to see the history of commits for this may take a look at: > > http://github.com/kay21s/libyahoo2/commits/master > > There are still a couple of tasks remaining, which need to be done > before we do a release: > > 1) Test the code. I'm planning on working on an implementation for > ayttm, but given my current schedule, it may take quite long > 2) Add an additional copyright notice to source files that have > changed. Kay ought to be doing this, but he'll need commit rights for > it. Kay, you need to get a Sourceforge.net account and tell us the > username so that we can add you > > -- > Siddhesh Poyarekar > http://siddhesh.in > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by > > Make an app they can't live without > Enter the BlackBerry Developer Challenge > http://p.sf.net/sfu/RIM-dev2dev > _______________________________________________ > Libyahoo2-devel mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libyahoo2-devel > |
From: Siddhesh P. <sid...@gm...> - 2010-08-13 21:57:10
|
On Sat, Aug 14, 2010 at 2:03 AM, Ray Van Dolson <ra...@bl...> wrote: > Great work! We should get this into Fedora rawhide for testing... was > the API changed significantly enough that freehoo (and other linked > clients) would need to be changed as well? > If the client had implemented chat room support and it wants to revive it then yes, it has to be modified and rebuilt. For those that never had chat room support anyway, it ought to have no impact. If it does, then it is a bug in libyahoo2 that needs to be fixed. I don't think this aspect has been tested, but from the code review it looks ok to me. -- Siddhesh Poyarekar http://siddhesh.in |
From: Ray V. D. <ra...@bl...> - 2010-08-13 21:27:36
|
On Sat, Aug 14, 2010 at 02:00:24AM +0530, Siddhesh Poyarekar wrote: > Hi, > > Yahoo chat room support is now in trunk. Many thanks to Kai (Kay) > Zhang for this effort, which he made as part of his Fedora Summer > Coding project. The code obviously needs some review and testing, so > those interested, please feel free to pitch in. > > I expected git-svn to commit the patchset along with the history in > Kay's git repository, but unfortunately that did not happen. So those > who want to see the history of commits for this may take a look at: > > http://github.com/kay21s/libyahoo2/commits/master > > There are still a couple of tasks remaining, which need to be done > before we do a release: > > 1) Test the code. I'm planning on working on an implementation for > ayttm, but given my current schedule, it may take quite long > 2) Add an additional copyright notice to source files that have > changed. Kay ought to be doing this, but he'll need commit rights for > it. Kay, you need to get a Sourceforge.net account and tell us the > username so that we can add you Great work! We should get this into Fedora rawhide for testing... was the API changed significantly enough that freehoo (and other linked clients) would need to be changed as well? Ray |
From: Siddhesh P. <sid...@gm...> - 2010-08-13 20:30:33
|
Hi, Yahoo chat room support is now in trunk. Many thanks to Kai (Kay) Zhang for this effort, which he made as part of his Fedora Summer Coding project. The code obviously needs some review and testing, so those interested, please feel free to pitch in. I expected git-svn to commit the patchset along with the history in Kay's git repository, but unfortunately that did not happen. So those who want to see the history of commits for this may take a look at: http://github.com/kay21s/libyahoo2/commits/master There are still a couple of tasks remaining, which need to be done before we do a release: 1) Test the code. I'm planning on working on an implementation for ayttm, but given my current schedule, it may take quite long 2) Add an additional copyright notice to source files that have changed. Kay ought to be doing this, but he'll need commit rights for it. Kay, you need to get a Sourceforge.net account and tell us the username so that we can add you -- Siddhesh Poyarekar http://siddhesh.in |
From: Siddhesh P. <sid...@gm...> - 2010-08-09 06:09:21
|
Hi, I'll be merging in Kay's chat room code in today. Can someone please modify your clients and test against it, if this feature is relevant to you? Thanks, Siddhesh -- Siddhesh Poyarekar http://siddhesh.in |
From: Siddhesh P. <sid...@gm...> - 2010-07-31 17:57:59
|
On Sat, Jul 31, 2010 at 6:23 PM, kay <ka...@gm...> wrote: > So I can move the xml-parsing function into our lib, and define a new struct > to present to the client? Don't move the xml parsing function out; it will break backward compatibility. Only define a new struct to present to the client. -- Siddhesh Poyarekar http://siddhesh.in |
From: kay <ka...@gm...> - 2010-07-31 12:53:46
|
So I can move the xml-parsing function into our lib, and define a new struct to present to the client? Ok, I will implement it. Thanks, --Kay 2010/7/31 Siddhesh Poyarekar <sid...@gm...> > On Sat, Jul 31, 2010 at 7:50 AM, kay <ka...@gm...> wrote: > > If library do the work, then library should give the chat room > information > > to client to show it in its own way. > > And client must know the data structures used in the library in order to > > traverse the list. Is this a good way? > > Currently we're exposing the xml to the client to parse and do > whatever it wants with it. Additionally it would be nice if we define > some structures (some kind of a list) that store and present this > information. > > We can then deprecate the xml in a future release since it is likely > that the xml may change over time and we would want to protect the > client implementation from this change. > > > I just took a look at the YIM API and didn't find any information about > > chat room. > > To use the Y!M API, you will need to do a lot of porting; that > probably won't be feasible as part of your project scope. But yes, it > probably needs to be done in the future. Has anyone been able to > decipher the developer agreement to see any problems? I haven't had > the time to look at it recently. > > > -- > Siddhesh Poyarekar > http://siddhesh.in > |
From: Siddhesh P. <sid...@gm...> - 2010-07-31 07:14:04
|
On Sat, Jul 31, 2010 at 7:50 AM, kay <ka...@gm...> wrote: > If library do the work, then library should give the chat room information > to client to show it in its own way. > And client must know the data structures used in the library in order to > traverse the list. Is this a good way? Currently we're exposing the xml to the client to parse and do whatever it wants with it. Additionally it would be nice if we define some structures (some kind of a list) that store and present this information. We can then deprecate the xml in a future release since it is likely that the xml may change over time and we would want to protect the client implementation from this change. > I just took a look at the YIM API and didn't find any information about > chat room. To use the Y!M API, you will need to do a lot of porting; that probably won't be feasible as part of your project scope. But yes, it probably needs to be done in the future. Has anyone been able to decipher the developer agreement to see any problems? I haven't had the time to look at it recently. -- Siddhesh Poyarekar http://siddhesh.in |
From: kay <ka...@gm...> - 2010-07-31 02:21:18
|
If library do the work, then library should give the chat room information to client to show it in its own way. And client must know the data structures used in the library in order to traverse the list. Is this a good way? I just took a look at the YIM API and didn't find any information about chat room. Thanks --Kay 2010/7/31 Philip Tellis <phi...@gm...> > On 30 July 2010 08:25, kay <ka...@gm...> wrote: > > The question is: who should be responsible for maintaining the chat room > > information > > Now the libyahoo is designed to handle the raw packet to the client and > let > > the client to parse the xml content. The category and chat room > information > > is maintained by the client. > > In this way, libyahoo doesn't know if it has to send the request or use > the > > existing information. > > Thanks, > > you should probably also check if there are any caching HTTP headers > set, since that will tell you how long you should hold on to the list. > I think it's something the library should do. BTW, have you looked > into the new Y!M APIs? > > Philip > |
From: Philip T. <phi...@gm...> - 2010-07-30 20:12:19
|
On 30 July 2010 08:25, kay <ka...@gm...> wrote: > The question is: who should be responsible for maintaining the chat room > information > Now the libyahoo is designed to handle the raw packet to the client and let > the client to parse the xml content. The category and chat room information > is maintained by the client. > In this way, libyahoo doesn't know if it has to send the request or use the > existing information. > Thanks, you should probably also check if there are any caching HTTP headers set, since that will tell you how long you should hold on to the list. I think it's something the library should do. BTW, have you looked into the new Y!M APIs? Philip |
From: kay <ka...@gm...> - 2010-07-30 15:26:26
|
The question is: who should be responsible for maintaining the chat room information Now the libyahoo is designed to handle the raw packet to the client and let the client to parse the xml content. The category and chat room information is maintained by the client. In this way, libyahoo doesn't know if it has to send the request or use the existing information. Thanks, --Kay 2010/7/30 Siddhesh Poyarekar <sid...@gm...> > On Fri, Jul 30, 2010 at 3:54 PM, kay <ka...@gm...> wrote: > > Hi, all > > I am implementing the function of getting chat room categories and chat > room > > lists. > > About the information that has been received from the server, the chat > room > > lists can be > > 1) they can be stored and displayed it directly when the user wants to > get > > it again > > 2) delete it after they have been displayed, send request again to get > the > > information when user wants it next time > > Which is the better way to implement it? > > The lists ought to be stored, since it does not make sense to query > them all the time. At the same time, there should be another function > to refresh the list. So you will have: > > 1) a get_chatroom_list that returns a cached list if it exists or > retrieves the list from the server otherwise > 2) a refresh_chatroom_list that retrieves the list from the server > > You will of course need to choose good function names (yahoo_...) > since they will be exposed as part of the API. > > -- > Siddhesh Poyarekar > http://siddhesh.in > > > ------------------------------------------------------------------------------ > The Palm PDK Hot Apps Program offers developers who use the > Plug-In Development Kit to bring their C/C++ apps to Palm for a share > of $1 Million in cash or HP Products. Visit us here for more details: > http://p.sf.net/sfu/dev2dev-palm > _______________________________________________ > Libyahoo2-devel mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libyahoo2-devel > |
From: Siddhesh P. <sid...@gm...> - 2010-07-30 10:45:18
|
On Fri, Jul 30, 2010 at 3:54 PM, kay <ka...@gm...> wrote: > Hi, all > I am implementing the function of getting chat room categories and chat room > lists. > About the information that has been received from the server, the chat room > lists can be > 1) they can be stored and displayed it directly when the user wants to get > it again > 2) delete it after they have been displayed, send request again to get the > information when user wants it next time > Which is the better way to implement it? The lists ought to be stored, since it does not make sense to query them all the time. At the same time, there should be another function to refresh the list. So you will have: 1) a get_chatroom_list that returns a cached list if it exists or retrieves the list from the server otherwise 2) a refresh_chatroom_list that retrieves the list from the server You will of course need to choose good function names (yahoo_...) since they will be exposed as part of the API. -- Siddhesh Poyarekar http://siddhesh.in |
From: kay <ka...@gm...> - 2010-07-30 10:24:56
|
Hi, all I am implementing the function of getting chat room categories and chat room lists. About the information that has been received from the server, the chat room lists can be 1) they can be stored and displayed it directly when the user wants to get it again 2) delete it after they have been displayed, send request again to get the information when user wants it next time Which is the better way to implement it? Thanks, --Kay |
From: kay <ka...@gm...> - 2010-07-17 12:20:04
|
Thanks for your suggestions, I have modified the code and used Location field to find out the URL. 2010/7/13 Philip Tellis <phi...@gm...> >> Thanks for your suggestion, it works now =) > >> I cannot check the HTTP status, whether the captcha is correct or wrong, > the > >> HTTP status is always 301 > >> I find the "The document has moved" is to goto the content of the HTTP > >> message in order to find if what is sent is right or the URL of a new > image. > > If you just want to know the URL where a 301 sends you, then look for > the Location: HTTP header. That's what the HTTP spec says. The > content body may not always be there. > -- --Kay -- --Kay |
From: Siddhesh P. <sid...@gm...> - 2010-07-13 05:53:52
|
On Mon, Jul 12, 2010 at 9:53 PM, Philip Tellis <phi...@gm...> wrote: >>> Thanks for your suggestion, it works now =) >>> I cannot check the HTTP status, whether the captcha is correct or wrong, the >>> HTTP status is always 301 >>> I find the "The document has moved" is to goto the content of the HTTP >>> message in order to find if what is sent is right or the URL of a new image. > > If you just want to know the URL where a 301 sends you, then look for > the Location: HTTP header. That's what the HTTP spec says. The > content body may not always be there. > Ahh yes, thanks. And that is all the more reason to get some structure around the HTTP headers. -- Siddhesh Poyarekar http://siddhesh.in |
From: Philip T. <phi...@gm...> - 2010-07-12 16:23:36
|
>> Thanks for your suggestion, it works now =) >> I cannot check the HTTP status, whether the captcha is correct or wrong, the >> HTTP status is always 301 >> I find the "The document has moved" is to goto the content of the HTTP >> message in order to find if what is sent is right or the URL of a new image. If you just want to know the URL where a 301 sends you, then look for the Location: HTTP header. That's what the HTTP spec says. The content body may not always be there. |
From: Siddhesh P. <sid...@gm...> - 2010-07-12 11:20:00
|
2010/7/12 kay <ka...@gm...>: > Yes, but it is hard to have a general HTTP structure, since there are so > many fields in HTTP protocol > I think it is a good idea to divide the HTTP header and the HTTP content > It does not have to be a field for every header. The right way to do this would be something like: struct http_header { int type namevalue_pair headers[]; } where namevalue_pair would be something like: namevalue_pair { char *name; char *value; } It does not have to be the same as above, but I hope you get the idea. -- Siddhesh Poyarekar http://siddhesh.in |
From: kay <ka...@gm...> - 2010-07-12 10:44:50
|
Yes, but it is hard to have a general HTTP structure, since there are so many fields in HTTP protocol I think it is a good idea to divide the HTTP header and the HTTP content 在 2010年7月12日 下午6:32,Siddhesh Poyarekar <sid...@gm...>写道: > 2010/7/12 Siddhesh Poyarekar <sid...@gm...>: > > (Do a reply-all so that the response goes to the mailing list as well) > > > > 2010/7/12 kay <ka...@gm...>: > >> Thanks for your suggestion, it works now =) > >> I cannot check the HTTP status, whether the captcha is correct or wrong, > the > >> HTTP status is always 301 > >> I find the "The document has moved" is to goto the content of the HTTP > >> message in order to find if what is sent is right or the URL of a new > image. > > > > If it is just to find the captcha url then you can simply get away by > > looking for "a href" and then parsing the link within that tag. But if > > you want to be sure that you received the expected response from the > > server (HTTP 301 instead of, say, 404 or 500) then you ought to be > > looking for the response code and not the string. > > > > Ohh, and it would be a pretty neat idea to have something of an http > response struct passed back to the calling function, which will give > details about the http headers. Right now we simply hack through the > headers and choose what we want. > > > -- > Siddhesh Poyarekar > http://siddhesh.in > -- --Kay |