TDataSetSerializeConfig em ambiente MultiThread

[MicroprocessDev]

Estou escrevendo uma aplicação REST (em horse claro! :) ) e percebi que a classe TDataSetSerializeConfig gera uma instância singleton (class var FINSTACE) quando usando TDataSetSerializeConfig.GetInstance.

Sendo assim se na minha aplicação houver endpoints diferentes que precisam de configurações diferentes em por exemplo: DataSetPrefix ou CaseNameDefinition, usuários diferentes chamado endpoints diferentes que alteram estas propriedades do config podem gerar jsons com formatação indesejada.

Então pensei fazer 3 coisas no código do Dataset.Serialize para torná-lo mais fexível.

1. Criar um método New que devolve uma nova instância do DataSetSerializeConfig, mas que não preenche e nem use o "class var FInstance". Assim cada Endpoint poderia ter sua própria instancia da classe de config e desta forma não gerar nenhum problema em ambiente multithread.

2. Passaria a instancia local do DataSetSerializeConfig em métodos sobrecarregados de TDataSetSerializeHelper que internamente repassaria para o create do DataSetSerializeConfig. Logo caso o programador utilize os metodo já existentes no DatasetSerialize atualmente ele passariamos nil para o o create do DataSetSerializeConfig forçando o DataSetSerializeConfig usar o GetInstance singleton (garantindo a compatibilidade de codigos que atualmente usam o Dataset.Serialize).

3. Para evitar ficar destruindo o TDataSetSerializeConfig e ele se comportar mais ou menos como se comporta atualmente pensei nesta classe implmentando uma interface.

O que acha destas idéias vinícius? Quero fazer estas implementações mas gostaria que pudesse ir para o trunk master. Não queria ter de fazer um fork do projeto. Logo suas sugestões aqui são primordiais para definir o nosso progresso.

[viniciussanchez]

@microprocessgit achei interessante sim. Eu particularmente não tive essa necessidade ainda, e também não gostaria que minhas aplicações retornassem padrões diferentes em momentos diferentes. Prefiro ter uma aplicação que segue um padrão para todas as requisições. Seja formatação de JSON, data, etc. Mas talvez essa seja uma necessidade sua não sei. Mas se manter a compatibilidade com o que se tem hoje, acho que não teria problema não.