Hi Vadim, > Great goal, > > But i don't really understand the new system of error codes and new API > methods.... > I'm affraid with your current approach you are missing this goal
Well, let's talk about the error codes. In the old phapi, some function return an int, some function return nothing (void), some other function returns char*. This makes error handling quite difficult and incoherent. Now, every function in the new API will return OWPL_RESULT_SUCCESS in case of success, or another value of type OWPL_RESULT in case of failure, that makes error checking more coherent. Hence, the code would appear clearer to readers. For the new API set, some missing functions are be added and some are simply renamed to describe better what it does. For example, in the old phapi, there was no easy way to just create a call handle and set properties to the call before actually dial. The only functions intended for the purpose of making a call were phPlaceCallx, that dial and returned a call handle. With these function, we could not ask phapi to encrypt the call before dialing. This is now possible with the new API set: OWPL_LINE hLine OWPL_CALL hCall; .... owplCallCreate(hLine, &hCall); // Create a new call without dialing owplCallSetEncrypt(hCall, 1); // Set the call to crypted mode ... //Set other properties for the call here owplCallConnect(hLine, "sip:[EMAIL PROTECTED]"); // Dial the call > >2. To make it more extendable (Easier to add new functionalities with a > new > >Plugin system. Able to handle all kind of communication sessions (File > >transfer, VNC, etc.), not only voice and video. > > > > > > > This is WRONG, WRONG, WRONG. > For the moment there is only 2 sets of RFCs for SIP, which covers > VOIP and IM, > It is simply loss of time to try to implement things as file transfer > or VNC session establishement > using INVITE/200/ACK sequences before there is some standard way to do it. > The best approch is to simply use SIP MESSAGE with an XML payload > describing the session.... > and all this stuff should be handled by application itself and not by > phApi.... > So there is no reason to extend phApi with plugins in that direction. Event there is no RFC about File transfer or VNC with SIP, We prefer to use INVIVE/OK/ACK sequence because it was made to create a session. MESSAGE was not invented for this purpose. At least, one advantage that I can mention right away is that if the INVITE was sent and 3 minutes latter, the invited person hasn't accepted the INVITATION, the session is automatically closed thanks to SIP proxy (a 4xx timeout response will be sent by the proxy). The fact that the session was closed due to a timeout is handled by the SIP stack and an event will be sent to the Plugin (File transfer or VNC). The plugin itself doesn't need to launch a timer to handle this kind of issue (which is required if MESSAGE is used instead of INVITE). > Another point, wifo should be factored out in separate tree and no to > be part of wengophone.... For now phAPI is still dependent of some library in WengoPhone, which make it not very easy to be moved to a separate branch. We will try to remove these dependencies first, then it is not very important where PhAPI is put, it will be independent and can be used without WengoPhone. Regards, Minh _______________________________________________ Wengophone-devel mailing list [email protected] http://dev.openwengo.com/mailman/listinfo/wengophone-devel
