Some bonus thoughts: What if we start from different side and implement a wrapper (i.e. class FileName) that encapsulates actual file name string (no matter how it is stored internally)?
Then we could create some similar wrapper that use our FileName class instead of any strings. This would give us clear transition points between internal UTF-8 representation and real file system. This would require more effort, because there are other functions that deal with file names directly. For example composing path from multiple components. As far a I understand currently it's implemented via GLib routines. Since we're anyway migrating from it such reimplementation would be required anyway (some code might be directly imported from GLib I think). What do you think about such approach? -- Denis ------------------------------------------------------------------------------ Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery and much more. Keep your Java skills current with LearnJavaNow - 200+ hours of step-by-step video tutorials by Java experts. SALE $49.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122612 _______________________________________________ Musicpd-dev-team mailing list Musicpd-dev-team@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/musicpd-dev-team
