Should the character encoding in database be normal (not HTML-encoded) and encode them on the output media/channel when they are needed?

[zybersup]

I have developed some applications using database of FrontAccounting to extend other functions we need to use. One of the annoying problem is about the encoded data in the database which are HTML encoded in many data. The data I often used are the name and description of items ('description' and 'long_description' fields in 'items' table).

When I just want to send or export them to the other applications as XML or JSON, I have to decode them back to normal before encoding them to the targeted media or platforms later. Sometimes they are double encoded in the database.

To make software more modular, the encoding process should be done at the place they need. For example, HTML encoding will be done when the data will be displayed on web browsers.

Is there anyone want to set a new standard of encoding data in FrontAccounting to make it more interoperable with other software by storing data in simple normal text rather than HTML encoded and using a correct encoding functions on each media they are going to be displayed. It might need time to change but I think it is worthy.

[c-git]

It might be worthwhile but it's a backward incompatible change so shouldn't be taken lightly.

[zybersup]

It might be worthwhile but it's a backward incompatible change so shouldn't be taken lightly.

Totally understood.

Could it be branched and let us choose the version we want?

[c-git]

I'm not sufficiently familiar with how this project runs to know if that would make sense but my feeling is that it would be better to choose one way instead of trying to maintain branches. But we'll see what the maintainer's think