Felix -- > > So the general way of dealing with these sorts of issues is to precede
> > characters that would otherwise be misinterpreted with a special > > character (generally "\") so that the data that is reconstructed on > > the receiving end is bit-for-bit identical with the data on the > > sending end. See: > > > > > https://developer.mozilla.org/en/Core_JavaScript_1.5_Guide/Core_Language_Features#String_Literals > > > > for details on the system used by PSON/JSON/etc. Note especially that > > there are provisions for Latin1 using /x__ where the "__" is a pair of > > hex digits specifying the eight bits needed to represent the > > character. > > So this would be the correct way of dealing with this without support > for internationalization? > I can see how this is technically sound, but from a usability > perspective, it's nightmarish. Requiring all team members to insert > cryptic escape sequences in texts makes all this a pointless exercise - > people could rather substitute the non-ASCII letters than do this. > We aren't communicating. PSON is how the puppet master exchanges data with the agents. No one needs to hand code the PSON, it is produced and consumed by software on both ends. And by design it is capable of expressing arbitrary binary data (that is, any data that you want) in appropriate contexts and so should not impose a limitation on what you can or can't send. If it doesn't work this way we would consider it a bug. > >> Even if that was the case, I guess we might as well go ahead and convert > >> the manifests and templates to UTF8, instead of messing with our Latin1 > >> texts. > > > > Where are you seeing the problems? Are there file contents specified > > in your manifests that are not being transmitted properly or...? If > > you could provide some examples it might help identify the problem. > > Of course. Consider this: > > file { "/etc/motd": content => "Testserver01 - Testsystem für Team1\n" } > > (Note that I'm encoding this mail in UTF8, but just imagine the manifest > to be, say, latin1 ;-) > > This is what puppetmaster 0.25.5 will throw at me when the client > requests PSON serialization: > puppetmasterd[5384]: Could not render to pson: invalid utf8 byte: '�' > > (That next to last character is supposed to be a ? glyph, but it doesn't > really matter). > > Serialization fails for such manifests and puppetd cannot run. > > I haven't had a chance to test 2.6, but the PSON code hasn't changed. > > The central question is - are such manifests to be acceptable or not? > Off the cuff, I would say that that (arbitrary data in a content string) ought to work. We've had some case (e.g. http://projects.puppetlabs.com/issues/3086) with non-seven-bit data in semantically significant places (puppet language syntax, some resource names, etc.) where not even unicode was permitted. But here it would seem that 1) the string should parse correctly and 2) it should serialize / deserialize correctly. > If I'm reading you correctly, you suggest that all non-ASCII content > should be required to be escaped. Is that notion shared by the community? > See above; the escaping I'm talking about is in the transport layer, not anything users should need to see. > Thanks for bearing with me, > No worries, that's what we're here for. -- Markus ----------------------------------------------------------- The power of accurate observation is commonly called cynicism by those who have not got it. ~George Bernard Shaw ------------------------------------------------------------ -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
