To me it felt, like you argued against fixing the documentation and rather 
restrict the types you want to accept. But obviously this is not the case...

Ok, then I am going to fix the documentation and close 
https://issues.apache.org/jira/browse/SLING-8314 
<https://issues.apache.org/jira/browse/SLING-8314> as "Works as Designed" 
without merging the attached PR.
Also I am gonna document the limitations of the write back (which are the same 
as the limitations of the .config file format).

> On 14. Mar 2019, at 13:27, Karl Pauls <[email protected]> wrote:
> 
> On Thu, Mar 14, 2019 at 1:04 PM Konrad Windszus <[email protected]> wrote:
>> 
>> 
>> 
>>> On 14. Mar 2019, at 11:23, Konrad Windszus <[email protected]> wrote:
>>> 
>>> 
>>> 
>>>> On 14. Mar 2019, at 10:19, Karl Pauls <[email protected] 
>>>> <mailto:[email protected]>> wrote:
>>>> 
>>>>> So I don't agree with
>>>>>> The point that we for the writeback don't
>>>>>> convert is hence, technically, a bug.
>>>> 
>>>> It is - assuming we hold our documentation to be the source of what we
>>>> support :-).
>>> Since the implementation was there first before Carsten added the 
>>> documentation I would rather say it is a documentation issue.
>> 
>> Also it says in 
>> https://sling.apache.org/documentation/bundles/configuration-installer-factory.html#configuration-files-config-
>>  
>> <https://sling.apache.org/documentation/bundles/configuration-installer-factory.html#configuration-files-config->
>> "Configuration files ending in .config use the format of the Apache Felix 
>> ConfigAdmin implementation 
>> <https://github.com/apache/felix/blob/trunk/configadmin/src/main/java/org/apache/felix/cm/file/ConfigurationHandler.java>."
> 
> Yes, thats what it is using to handle the format specified directly below it.
> 
> I'm not sure what you are trying to argue for at this point. As I
> said, I'm not against changing the definition - all I'm saying is that
> in case we do, we should define how we handle the writeback because we
> then run into changing config files depending on who touched them
> last. Furthermore, as there is no specification for the Felix class we
> should still define what we expect in the format and obviously, as far
> as we specify something that isn't working yet, implement that (and
> probably stop hot linking to some class in Felix trunk).
> 
> regards,
> 
> Karl
> 
> 
> -- 
> Karl Pauls
> [email protected]

Reply via email to