[reSIProcate] Open issues remaining for 1.1 release

[Robert Sparks]

limpc must continue to work.
We can remove PidfContents from it if we want the class to go away. I  
don't know if we can do that in time for 1.1. I will look at it  
tomorrow.

RjS

On Feb 21, 2007, at 5:25 PM, Byron Campen wrote:

> 	Well, looking at this, there is still a fair amount of code that  
> uses the Pidf stuff. limpc, for example, relies on this code. There  
> are a bunch of test-cases that use Pidf as well. I do not think I  
> am prepared to toss all this stuff out for this release.
>
> Best regards,
> Byron Campen
>
>> With respect to old issue E(XML parsing support for XML)
>>
>> I think since RPID support is becoming more common, now is the  
>> time to deprecate our XML parsing in resip.  We can:
>>
>> 1. make it a configure option, which doesn't rwork well for  
>> windows/mac project files and not use PidfContents in tests
>>
>> 2. completely remove PidfContents from resip & all XML parsing  
>> code.  I have had several bad product builds resulting from the  
>> accidental inclusion of Pidf.cxx: "I put it in the solution, it  
>> was in the resip directory...." is the usual quote.
>>
>> Personally, I vote for #2.
>>
>> -Derek
>>
>> On 2/12/07, Byron Campen <bcampen at estacado.net> wrote:
>> 	Here's the current rundown...
>>
>> New open issues.
>>
>> New issues with some work remaining:
>> 1. Dealing with quoted qop (see [reSIProcate] qop Parameter  
>> Parsing) (working)
>> 3. Problem with SharedPtr on Solaris ( see [reSIProcate] Bugs in  
>> SharedPtr and SharedCount of ReSip1.0 when using libCstd compiling 
>> (not libstlport4) on SOLARIS ) (unknown, probably standards- 
>> compliance issue in libCstd)
>> 6. API problem in SipStack::addTransport() (see [reSIProcate]  
>> Creating a DUM with automatic port? ) (offending default port  
>> removed, might be nice to have the ability to tell the stack to  
>> open a transport on an ephemeral port)
>> 9. install target issues with dum and stack ( see [reSIProcate]  
>> Minor Makefile issues ) (patch applied, have not fixed install  
>> path for ares)
>> 10. Possible heap corruption on deletion of SipStack ( see  
>> [reSIProcate] Crash in ares on deleting SipStack ) (following up  
>> on list, probably a link error)
>> 16. Update license blocks. (see [reSIProcate] Copyrights)
>>
>> Solved:
>> 5. Empty contents problem in client publish code in DUM ( see  
>> [reSIProcate] [PATCH] Empty PUBLISH body if there is a pending  
>> publish ) (resolved, patch applied)
>> 7. V6 address storage problem in Tuple (see  [reSIProcate] IPv6  
>> address in Via header gets its lower order bits chopped off (Win32  
>> platform)) (resolved, patch was applied)
>> 8. Possible problem in SdpContents::getBodyData() ( see   
>> [reSIProcate] SdpContents::getBodyData() returns stack pointer )  
>> (resolved, third-party problem)
>> 12. Possible failure in DUM unit test ( see [reSIProcate] DUM test  
>> fails ) (resolved)
>> 13. Problem with merged-request detection in DUM (see  
>> [reSIProcate] Call routed back to reSIProcate by SipX PBX after  
>> 302 temp moved .) (resolved)
>> 14. Shared library build broken on x86_64 ( see  [reSIProcate]  
>> building shared libraries on AMD64) (fixed, backported)
>> 15. Problems with unsolicited NOTIFY in DUM ( see [reSIProcate]  
>> refer with refSub = false stillcauseClientSubscriptionHandler be  
>> used ) (fixed, backported)
>> 17. configure script error on Ubuntu ( see Re: [reSIProcate] Open  
>> issues for 1.1 release) (fixed, backported)
>> 18. repro/debian/patches, does this still belong here?( see  Re:  
>> [reSIProcate] Open issues for 1.1 release)
>> 19. Symlinks to binaries are no longer created. (fixed, backported)
>> 20. Build is hosed on OS X (fixed, backported)
>> 21. The "u=" is not encoded before the Uri of description in  
>> SdpContents::Session::encode() (see [reSIProcate] Bug in  
>> SdpContents encode method) (fixed, backported)
>>
>>
>> Old open issues:
>> A.  URI parsing bug in XMLCursor???
>> B.  Not using PrivateKey pass phrases at all.  All private keys  
>> must be
>> unencrypted on the disk.
>> C.  Change to DateCategory to make is more compatible with other
>> implementations.  (slight problem, needs discussion: see  
>> [reSIProcate] Revisiting parse code for DateCategory)
>> D. Parser validation issues from Kayote. (Contact * can be allowed in
>> any Nameaddr) (needs discussion)
>> E. PIDF XML parsing support for XML namespaces - The patch was not
>> applied, not addressed. Derek says we may want to deprecate our XML
>> parsing stuff; this will end up making A moot as well. (If the  
>> decision is to deprecate, lets go ahead and do it already.)
>> F. No support for /etc/hosts file
>> H. Maybe having a ThreadIf::detach() would be nice. Not addressed, or
>> discussed. (see [reSIProcate] adding detach to ThreadIf )
>>
>>
>>  	I would like to have a release candidate by next Wednesday. This  
>> should not be hard to do, I think. At this point, I'd like  
>> everyone who has done significant work since the last release to  
>> mail me a list of what they have done, so we can make the release- 
>> notes.
>>
>> Best regards,
>> Byron Campen
>>
>>
>>
>> _______________________________________________
>> resiprocate-devel mailing list
>> resiprocate-devel at list.resiprocate.org
>> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>>
>>
>
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel at list.resiprocate.org
> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20070221/286e076b/attachment.htm>