On Fri, 2007-09-07 at 10:32 -0400, Owen Taylor wrote: > I'd consider the two things actually quite distinct: > > * D-BUS object path: you want a *unique* *consistent* representation of the > bytes of the ESSID. So you might, say, treat them as bytes and do URI-style > %XY escaping of bytes that aren't legal ascii characters in the context +1. It's so easy with computers. Just set a standard (URI specification) and it starts to make sense everywhere. If we assume that no human will look at the D-BUS object path except likely the developers, then you can just adopt whatever's convenient for the devs. ASCII characters seem to be common for them. > * Display to the user: you want to make a best guess at the encoding and try > to display the exact same thing that someone typed into the router > configuration, > rather some unique-but-looks-like-garbage escaped version. At least with documents, there's a lot of heuristic to work on to make sense (encoding) of the the data. With ESSIDs, you're limited to 32-bytes and aren't even quite sure that they were meant to be treated as text. I don't envy the team tasked to design the algorithm for this, but I'm guessing first, they've to determine if it's supposed to be human-readable (0x00 bytes interspersed between non nulls is one indication). Otherwise, re-use some existing code to determine encoding. P.S. As much as I love reading about this issue, it probably does belong to a NetworkManager / nm-applet bugzilla or forum. -- Richi Plana -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
