Menu
▾
▴
libyahoo2-devel
|
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: 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 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: 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-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: 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 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 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 |
Thanks for helping keep SourceForge clean.
X