> > > Be aware of CPU "endian-ness". This is a concern in Intel to Sparc > > > porting. Not sure about HP to Sparc. Google on "endian" for more info. > > > It may only be a concern if you exchange binary information with other > > > computers in units large than a byte (octet of bits). > > In which case you should probabily be using network byte ordering or > > whatever the respective standard defines. Or using plain text - in > > theory endian-ness isn't a problem. However this is the real world... > Do you mean to tell me that XML is _not_ taking over the world? In some applications. I'm more interested in lower level software. There is no XML version of machine code or IP - and something tells me there never will be :-) IMHO XML is a very good tool for some tasks and like lots of good ideas it seems to have been hijacked and now we're being told it will solve anything.
> I tried > xerces and C++ and after a week of reading and testing, I decided to try it > again some other time. Can it be that managing endian-ness is easier than > using XML from a developer point of view? In some cases. Sun-RPC handles it automatically, you have the functions in <netinet/in.h> (see man byteorder(3)). I'd use XML cos your application needs it and it's a good idea not just because it handles byte ordering. > Oh sure, XML is great from a user perspective, And an openness / interaction sense. > but goodness, don't those apps swell up when XML parsing is > linked in? Hence suggestions about standard XML parser dynamic libraries as well as dynamic XML parser generator tools so you can handle any sort at run time. I would say there are ways round this. Seeing as this is getting a tad OT - can I suggest any further discussion of XML/endian-ness/software interoperability issues are taken off list. Sweet Dreams, - Martin -- Martin [EMAIL PROTECTED] "Seasons change, things come to pass"
