Feature #429
Make middleware unicode friendly
| Status: | Closed | Start date: | ||
|---|---|---|---|---|
| Priority: | High | Due date: | ||
| Assignee: | % Done: | 0% |
||
| Category: | Middleware | |||
| Target version: | 2nd | |||
| Resolution: |
Description
This is a massive change, requiring changes at all levels (core, middleware, application). In short, absolutely all strings handled within the application need to be unicode objects and they need to be encoded when they leave the application/decoded when they enter it:
- when writing/reading to/from files
- since pjsip is not unicode friendly, when sending/receiving data to/from pjsip
- ideally, msrplib should be unicode friendly; if not, data should be encoded/decoded when sending/receiving data to/from msrplib
- in the case of the sipclients scripts, strings should be encoded/decoded just before/after writing/reading to/from the terminal using the encoded determined from the environment; the sipclient.ui module will probably be the one which needs to be modified and then scripts other than sip-session adapted to use it
- fortunately, in the GUI applications no encoding/decoding is necessary since the libraries used take care of this (these need to make sure they only work with unicode objects and all data exchanged with the middleware is unicode)
- the only part of the middleware which is unicode friendly is the configuration framework; however, due to limitations in the rest of the middleware, settings have been forced to str-derived types and the configuration framework slightly modified to handle these; thus, when all the settings can be based on unicode-derived types, the configuration framework needs to be modified to no longer accept str-derived types.
History
Updated by Adrian Georgescu over 2 years ago
- Status changed from New to Closed
- Resolution set to implemented
Most relevant parts of the middleware are now unicode friendly. This ticket will be closed based on Pareto's principle.