Re: Revert "tdf#106283: Registry settings are not read properly on Windows"

On 03/07/2017 10:00 AM, Zolnai Tamás wrote:
> > So coming back to <https://gerrit.libreoffice.org/#/c/34933/>, I'm not too
> > excited about that hack.  It's a quick-fix to work around one specific
> > shortcoming of the naive Windows registry mapping, but in a way that would
> > require that hack to stay for backwards-compatibility reasons even when/if a
> > more principled fix for that mapping is done.
>
> What do you mean by that "would require that hack to stay for
> backwards-compatibility reasons"? Why? Do you mean that if now we

What I meant is:

Encoding an extension prop in the Windows registry is not possible today 
(because the encoding lacks type information).  So a Windows registry 
instance containing an extension prop (necessarily lacking type 
information) is invalid input to LO.

Gerrit 34933 makes valid certain such invalid inputs.  Users will rely 
on this by providing such inputs.

And users will expect that such inputs remain valid in the future.  (Or 
would you be fine with incompatibly forbidding such inputs again in the 
future?)  Which implies that we'll need to keep the code from Gerrit 
34933 around.

> handle a property without an explicit type (inside an extensible
> group), than this will be required in the future too? As I see config

Yes.  If we now give meaning to certain so-far invalid inputs, we'll 
probably need to continue to do so, see above.

> manager works on the same way for other properties which are not
> member of an extensible group. It's also an invalid thing, right? And

I don't understand this part.

> also the temporary xcu file is generated by LibreOffice, so I hope
> nobody uses this temporarily generated xcu file as a template or
> something like that.

I'm not sure what the temporary xcu files have to do with this.

> Also I think that principle fix you mentioned is not something which
> would be allowed to push to a bugix branch, so I think it's better to
> make it work, if users use it. Of course you are right on that this
> windos registry handling can be improved.

What's wrong with the approach of adding a "Type" key?  For its legal 
values use strings, either the "canonically namespace-prefixed" values 
(cf. officecfg/registry/component-update.dtd)

  "oor:any", "xs:boolean", "xs:short", "xs:int", "xs:long", 
"xs:double", "xs:string", "xs:hexBinary", "oor:boolean-list", 
"oor:short-list", "oor:int-list", "oor:long-list", "oor:double-list", 
"oor:string-list", "oor:hexBinary-list"

or the raw

  "any", "boolean", "short", "int", "long", "double", "string", 
"hexBinary", "boolean-list", "short-list", "int-list", "long-list", 
"double-list", "string-list", "hexBinary-list"