[reSIProcate] Open issues remaining for 1.1 release

[Byron Campen]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20070221/e1c8a900/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2423 bytes
Desc: not available
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20070221/e1c8a900/attachment.bin>