[reSIProcate] Open issues remaining for 1.1 release

[Derek MacDonald]

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/44289de7/attachment.htm>