I had a thought about this issue this morning: 1. The XML export without libxml2 should be pretty easy (right?).
2. If we're importing exactly what was exported, that should also be pretty easy without libxml2 (right?). Meaning: there can be a very simplistic parser that only handles the expected ordering/cases/whatever that comes from #1. 3. If the simplistic XML parser in #2 fails, it can fall back to libxml2's importer for a "full" XML import (if libxml2 is available, of course). Or, you could reduce these two down to the following: 1. If libxml2 is present, use it for both export and import. 2. If libxml2 is not present, use a simplistic exporter and importer. If the simplistic XML importer fails, show a helpful message "Compile hwloc with libxml2 for full XML import support," or something like that. On Sep 6, 2011, at 12:33 PM, Brice Goglin wrote: > Le 06/09/2011 17:39, Jeff Squyres a écrit : >> On Sep 6, 2011, at 11:25 AM, Brice Goglin wrote: >> >>>> - I don't know where we ended up in the other thread: do we want JSON or >>>> no? If we can parse it easily without an external dependency, then I >>>> think it's worthwhile. >>> I stopped working on JSON this to see where the idea of reimplementing >>> our own XML parser would go. >> Beyond your prior emails on this, any further thoughts? Especially if we >> restrict to ASCII-only? > > I would they that French developers are used to cast their names into > ASCII. So restricting hwloc to ASCII would be ok for me. I am not sure I > will use my name or my institution as a topology attribute anyway :) > > I don't have any non-ASCII char in my name or institution so I am open > to other opinions :) > > Brice > > _______________________________________________ > hwloc-devel mailing list > hwloc-de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel -- Jeff Squyres jsquy...@cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
