Re: [Wengophone-devel] branches and wifo-refactoring

[Vadim Lebedev]

Quang Minh Phan wrote: 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. This is inexact.... ALL functions returns int except 3 which are void... (phTerminate, phSetDebugLevel, phRefresh - which are actually internal function). All these ints are error codes from the same enum except phGetVersion which return phApi version The error codes are arranged so that 0 means success I don't really think there is much incoherency and that this particular aspect needs further simplification 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. I completley disagree with the idea that        if (call() == OWPL_RESULT_SUCCESS)           {              bla; bla; bla;            } is more readable than     if (!call())        {           bla;bla;bla;         } in the second  case signal to noice ratio is much better than in the first case   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 This kind of problem can be solved by adding ENCRYPTION bit to streams parameter in phLinePlaceCall2 IMO owplXXXX  approach is more complicated to use  (but  one  can argue that  it is matter of taste) It is definetevly more consice to write         phLinePlaceCall2(vl,  uri, 0, 0,  PH_STREAM_ENCRYPTION|PH_STREAM_ALL) than: owplCallCreate(hLine, &hCall); // Create a new call without dialing owplCallSetEncrypt(hCall, 1); // Set the call to crypted mode ... //Set other properties for the call owplCallSetStreams(hCall, PH_STREAM_ALL) owplCallConnect(hLine, "sip:[EMAIL PROTECTED]"); // Dial the call I understand that this owplXXXX stuff was needed in order to implement non A/V media types but as i argue IMO there is NO actual need to implement non A/V media types in phApi   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). You mean you added 5th weel to the phApi only to handle timeouts? wengophone already handle various timeouts, it is pretty easy given usage of boost to add another timeout to handle this specific problem. I REALLY don't understand the reasoning, it was SO MUCH SIMPLER to do it using SIP MESSAGE request and HTTP transfer, than to develop SDP plugin framework for phApi The price/performance ratio with respect of developpement effort of  your approach is abysmall... 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. Well i'm actually already maintaining a branch which is independent of  Wengophone.... so if you wish you simply need to take it Thanks Vadim P.S. Folks may be i'm a simply stubborn dumbass so please voice your opinions on the  issue.... I don't want  this  discussion simply to be pissing contest between me an Minh

_______________________________________________
Wengophone-devel mailing list
Wengophone-devel@lists.openwengo.com
http://dev.openwengo.com/mailman/listinfo/wengophone-devel