XML vs regular commands

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hi

In a certain project I need to send and receive commands and status info t
other processes. Each command would have some parameters (fixed set pe
command), status info would have some fields (also fixed). The commands an
status info are sent over sockets because the other processes could b
located on different servers/platforms. Another requirement is that th
commands and status info have to be parsed and executed as fast as possible
Timing is critical, because the other processes drive robotic parts

I was wondering if it would make any sense to use XML for the commands an
the status info. I know a bit about XML, but I've never used it before.
know that .net has class(es) to process the xml files but I worry abou
performance. The XML commands would probably need some dtd or xsd fo
validation, in order to be used by the xml-parse classes (I don't know). I
looks like it would take a lot longer to parse an xml command usin
xml-parse classes, than it would by just manually parsing a byte command. O
the other hand, i think using xml would make it easier to programme. It wil
take some time before I can actually test this all, so

I would like to hear any opinion on this matter

Thank you
PS: I also posted to microsoft.public.dotnet.xml, but my platform could be embedded XP I don't know yet
 
Hi,

Cold me old fashioned, but I would never use any programming language or
technology higher than C++.
I have no idea what XML can do and how fast it can do it, but it will never
be able to match speed of using API directly or writing driver program that
uses NDIS or TDI directly.

One thing why you should avoid fancy things like XML, .Net framework, etc.
Is because they will triple size of your XPe image (You can make very small
images using minlogon).
And more components you have in your image, more likely that there will be
some security hole. Also you will need to track and apply new QFE's more
often.
If XML is only thing you know, and you use it for other purposes then this
could be only reason why to use it.
Also you should consider that this may be good for you, but your customers
needs like reliable system should come first. So if you can use API more
directly as in C++ then you should use it.

Regards,
Slobodan

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Have an opinion on the effectiveness of Microsoft Embedded newsgroups? Tell
Microsoft!
https://www.windowsembeddedeval.com/community/newsgroups
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
----- Slobodan Brcin (eMVP) wrote: ----
technology higher than C++

I wouldn't call you old fashioned, my first idea was to actually use c++. Company policies however suggested I'd use c#. Howeve,r if I decide that C# is not the way to go, then it will be in c++
I have no idea what XML can do and how fast it can do it, but it will neve
be able to match speed of using API directly or writing driver program tha
uses NDIS or TDI directly

I know. But just how fast can parsing xml commands be? If it is fast enough and it always takes the same time to parse the commands, then it is sufficient.
But I worry about performance (of course). I am already crawling back from the idea of using xml

Can you tell me what NDIS & TDI are
One thing why you should avoid fancy things like XML, .Net framework, etc
Is because they will triple size of your XPe image (You can make very smal
images using minlogon)

Doesn't c# have some switch to compile to asm instead of to cli
Anyway, embedded java exists so I thought c# would have something similar.
And more components you have in your image, more likely that there will b
some security hole. Also you will need to track and apply new QFE's mor
often
QFE

If XML is only thing you know, and you use it for other purposes then thi
could be only reason why to use it
Also you should consider that this may be good for you, but your customer
needs like reliable system should come first. So if you can use API mor
directly as in C++ then you should use it
Sloboda

Thanks
Tom
 
Hi Tom,
I wouldn't call you old fashioned, my first idea was to actually use c++.
Company policies however suggested I'd use c#. However if I decide that C#
is not the way to go, then it will be in c++.

Well marketing phrases like "Our robotic parts are guided by C# and XML...."
sounds very in and high tech. But if you look from developer side this
sounds very bad. I don't say that you should use ASM since on Windows it
would not make difference, but you should have at least some touch with your
hardware, Windows API or some drivers will give you that. But for this
particular purpose especially if you don't have GUI you should choose
something like C/C++.
I know. But just how fast can parsing xml commands be? If it is fast
enough and it always takes the same time to parse the commands, then it is
sufficient.
But I worry about performance (of course). I am already crawling back from
the idea of using xml.

This even MS can't tell you, since this can change with each Windows update.
Also if you are really planning to use XPe in future this can make
unnecessary need to use big XPe image. 130-250 MB instead of 30-60 MB.
(Consider this if you want to put your OS on compact flash)
Can you tell me what NDIS & TDI are?
Something that your marketing guys probably don't want you to use. Those are
driver level network interfaces.
More info about:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/network/hh/
network/netref_886q.asp
Doesn't c# have some switch to compile to asm instead of to cli?
Anyway, embedded java exists so I thought c# would have something similar.

Image size is because you must use .NET framework.

They are updates/fixes for various issues with Windows XP/XPe. So is you use
less things them less of these updates will be relevant to you.

Regards,
Slobodan

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Have an opinion on the effectiveness of Microsoft Embedded newsgroups? Tell
Microsoft!
https://www.windowsembeddedeval.com/community/newsgroups
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
Back
Top