libyahoo2-devel — A list for the libyahoo2 development team

Re: [Libyahoo2-devel] ABI breakage with chat room changes

[kay <ka...@gm...>]

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
>

[Libyahoo2-devel] ABI breakage with chat room changes

[Siddhesh P. <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

Re: [Libyahoo2-devel] Doxygen documentation for libyahoo2

[Siddhesh P. <sid...@gm...>]

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

Re: [Libyahoo2-devel] Doxygen documentation for libyahoo2

[Tri S. <st...@gm...>]

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
>

[Libyahoo2-devel] Doxygen documentation for libyahoo2

[Siddhesh P. <sid...@gm...>]

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

Re: [Libyahoo2-devel] Wrong handling of status in yahoo_process_buddyadd()

[Siddhesh P. <sid...@gm...>]

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

[Libyahoo2-devel] Wrong handling of status in yahoo_process_buddyadd()

[Wilmer v. d. G. <wi...@ga...>]

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 |
+--- -- -  ` ---------------+  +------ ----- ---- --- -- -        +

Re: [Libyahoo2-devel] yahoo chat room support now in trunk

[kay <ka...@gm...>]

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
>

Re: [Libyahoo2-devel] yahoo chat room support now in trunk

[Siddhesh P. <sid...@gm...>]

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

Re: [Libyahoo2-devel] yahoo chat room support now in trunk

[Ray V. D. <ra...@bl...>]

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

[Libyahoo2-devel] yahoo chat room support now in trunk

[Siddhesh P. <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

[Libyahoo2-devel] Heads up: chat room code merge today

[Siddhesh P. <sid...@gm...>]

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

Re: [Libyahoo2-devel] Need to store the chat room information?

[Siddhesh P. <sid...@gm...>]

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

Re: [Libyahoo2-devel] Need to store the chat room information?

[kay <ka...@gm...>]

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
>

Re: [Libyahoo2-devel] Need to store the chat room information?

[Siddhesh P. <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

Re: [Libyahoo2-devel] Need to store the chat room information?

[kay <ka...@gm...>]

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
>

Re: [Libyahoo2-devel] Need to store the chat room information?

[Philip T. <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

Re: [Libyahoo2-devel] Need to store the chat room information?

[kay <ka...@gm...>]

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
>

Re: [Libyahoo2-devel] Need to store the chat room information?

[Siddhesh P. <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

[Libyahoo2-devel] Need to store the chat room information?

[kay <ka...@gm...>]

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

[Libyahoo2-devel] Fwd: A Problem

[kay <ka...@gm...>]

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

Re: [Libyahoo2-devel] A Problem

[Siddhesh P. <sid...@gm...>]

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

Re: [Libyahoo2-devel] A Problem

[Philip T. <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.

Re: [Libyahoo2-devel] A Problem

[Siddhesh P. <sid...@gm...>]

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

Re: [Libyahoo2-devel] A Problem

[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

在 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