potentially, but checking against schemas isn't free.
depending on the application, it could be hard to justify spending the
extra clock cycles (except maybe for debugging purposes or similar).
On 12-02-09 12:15 PM, BGB wrote:
On 2/9/2012 3:24 AM, Arved Sandstrom wrote:
[ SNIP ]
Consider line-oriented files/messages like .properties files: these
can
describe hierarchical structures perfectly well if you've got an
understood key=value syntax, specifically with a hierarchy-supporting
syntax for the keys. Easy to read and edit, easy to parse.
yes, but this defeats your own prior point, namely indirectly asserting
that line-oriented == flat-structure.
Minor quibble, I didn't make such a point, not even indirectly. You may
be confusing me with Arne.
point is, one can have hierarchical line-oriented files.
[ SNIP ]
Yes.
You can have non flat structures other than XML, but parsing
quickly becomes very complex.
IMO: not particularly...
tree-structured line-oriented text formats are not that much more
complicated to parse than flat-list line-oriented text formats (the only
obvious difference is that rather than a single loop, one typically has
multiple loops).
it all still basically amounts to:
read a line;
split the string;
do something with the split strings.
personally, I like recursive hand-written descent parsing, as it is
fairly straightforwards and doesn't depend on external tools.
On 2/9/2012 3:24 AM, Arved Sandstrom wrote:
On 12-02-08 10:50 PM, BGB wrote:
On 2/8/2012 7:16 PM, Arne Vajhøj wrote:
On 2/8/2012 2:07 PM, BGB wrote:
On 2/8/2012 4:19 AM, Arved Sandstrom wrote:
On 12-02-08 04:41 AM, BGB wrote:
note: my main way of working with XML is typically via DOM-style
interfaces (if I am using it, it is typically because I am
directly
working with the data structure, and not as the result of some
dumb-ass
"data binding" crud...).
I haven't been able to completely avoid using the DOM, but I
loathe the
API. If I'm using XML at all, and JAXB suits, I'll use JAXB. More
generally I'll use SAX or StAX.
I have rarely done things for which SAX has made sense...
usually in cases where SAX would make sense, I end up using
line-oriented text formats instead (because there is often little
obvious reason for why XML syntax would make much sense).
Non flat structure and validation comes to mind.
fair enough.
often, one can implement non-flat structures with line-oriented
formats,
for example:
...
groupDef {
...
groupDef {
itemDef {
...
}
...
}
...
}
[ SNIP ]
No need for the braces, if you're going to use those all you gain over
the XML is terseness.
well, if the format is still line-oriented, one can still parse the
files using a loop, getting and splitting strings, and checking the
first token of each line.
parsing XML is a little more invovlved, since:
items may be split across lines, or multiple items may exist on the same
line;
one can no longer use whitespace or commas as the primary deliminator;
????
No one in their right mind would parse XML manually.
You can pick between lots of nice XML API's (many of them
shipping with Java) that will handle all that.
depends on which language one is using at the time...
if one is using Java, then XML parsing is basically free.
if one is using C, then it is either "write some code to do it", or
suffer with a 3rd party library dependency (one might validly choose to
write the code themselves in this case).
I don't expect it is all that uncommon for a person to switch between
several different languages, and maybe deal with the strengths and
weaknesses of whichever language they are using at the time.
BGB said:if one is using C, then it is either "write some code to do it", or
suffer with a 3rd party [sic] library dependency (one might validly
choose to
write the code themselves in this case).
"Suffer"? The XML parsers for C are well-established, very reliable,
and no
cause for suffering. Using a pejorative is not the same as establishing a
point.
There is nothing wrong with the third-party libraries, and the choice to
roll your own for C is rarely valid. You seem to suffer from NIH
syndrome.
they introduce porting hassles:
does one bundle "libxml" with their app on Windows;
do they use MSXML and then deal with having to switch over to "libxml"
when building on Linux?
but, anyways, it is like asking a person never to write their own JPEG
loader/saver, or their own scripting-language compiler. yes, maybe a
person doesn't technically need to, but they may forsake potentially
valuable learning experiences (or the claim to having the skills to do so).
This is the use case for which XML with schema excels. It is very nearly ideal
for the purpose. XML is semantically void with respect to the problem domain,
schemas provide a reliable contract for interpretation of the messages, they
provide a convenient human-readable format to ensure agreement by all
stakeholders, the drive the easy-to-use tools for XML-based message passing,
and such easy-to-use tools are abundantly available for every major platform
and computer language.
Your comments about different libraries' availability makes an asset sound like
a problem. It's a *good* thing that there are so many libraries available. XML
itself provides the compatibility.
Arne said:????
But that not how you work with XML.
You load it into a DOM and use XPath to pull
out what you need.
You need to depend on some tools.
If you use Java then you depend on standard Java library.
Standard Java library contains several XML parsers.
No extra dependency for Java.
One of the points is that you can validate during integration test
and if you encounter a problem but keep validation turned off otherwise.
And besides I would assume the big XML parser libraries to have
optimized the validation quite a bit.
Or you scan it with SAX or StAX and deal with XML-parsing events, or
you run the schema through JAXB and let it generate all the parsing
classes for you, or you use one of the many other standard libraries
in Java (or if not Java, in your favorite platform) that are available
for free.
The thing is, BGB, that your macho programming style is impractical
and not very justifiable. It's wonderful that you have reinvented the
programming world and all, and are so clever and knowledgeable, but
most of us programmers work in a workaday pragmatic environment where
best practices really do save the day. That means use the standards,
and the abundant tools that support them, and give up our egos that
make us feel that superman heroics are the only available path. I
sincerely hope that readers of this thread can understand the manifest
shortcomings of the approaches that you've espoused here. (And that
they can disentangle themselves from your fetching but irrelevant
analogies.) To get the job done, to get it done right, and to minimize both error and development time, use the standards.
XML is just fine for just about every purpose to which it's put.
That's why it's popular now. People who cavil about "bandwidth" and
"10 Hz network messages" are tossing us red-herring sashimi. You
aren't going to get 10+ Hz message exchanges over the WAN. For
realistic message rates, XML suits beautifully. I speak from
experience with many, many projects that used every conceivable
message format from binary to CSV to custom to XML to protocol buffers
to JSON, and XML has distinct advantages. Its purported disadvantages
of bulk and bandwidth turn out to be non-issues in practice. Really.
That's real.
Oh, yeah, micro-optimize that last $0.0000001 of performance.
Great thinking.
Checking against schemas isn't so expensive, either. You spout this drivel,
BGB, about "isn't free", but where are your numbers? Show us reality, dude -
exactly how "not free" is schema validation, under what loads, on what
platforms? Hm?
I thought not.
How many "extra clock cycles", and does it cost less than the damage your
development techniques cause?
Given that BGB is just spewing dream talk with zero or less than zero facts,
evidence or measurement behind it, it's pretty safe to dismiss his
"conclusions".
or such ...
BGB wrote:
if one is using C, then it is either "write some code to do it", or
suffer with a 3rd party [sic] library dependency (one might validly
choose to
write the code themselves in this case).
"Suffer"? The XML parsers for C are well-established, very reliable,
and no
cause for suffering. Using a pejorative is not the same as
establishing a
point.
There is nothing wrong with the third-party libraries, and the choice to
roll your own for C is rarely valid. You seem to suffer from NIH
syndrome.
they introduce porting hassles:
does one bundle "libxml" with their app on Windows;
do they use MSXML and then deal with having to switch over to "libxml"
when building on Linux?
LIBXML2 works fine on Windows, so you can use it on both platforms.
I think you should very clearly distinguish between when you talk about
learning and programming production code.
The goals are just so different.
On 2/10/2012 9:51 AM, Lew wrote:
BGB wrote:
if one is using C, then it is either "write some code to do it", or
suffer with a 3rd party [sic] library dependency (one might validly
choose to
write the code themselves in this case).
"Suffer"? The XML parsers for C are well-established, very reliable,
and no
cause for suffering. Using a pejorative is not the same as
establishing a
point.
There is nothing wrong with the third-party libraries, and the
choice to
roll your own for C is rarely valid. You seem to suffer from NIH
syndrome.
they introduce porting hassles:
does one bundle "libxml" with their app on Windows;
do they use MSXML and then deal with having to switch over to "libxml"
when building on Linux?
LIBXML2 works fine on Windows, so you can use it on both platforms.
yeah, it is an option.
however, it is not a standard library on Windows (in certain cases, one
may need to provide for it, or expect anyone who wants to build from
source to provide for it, ...).
in my case, both often end up being the same code.
one may end up doing something initially as a learning activity, but if
one does so, and the code works fairly well, why write the same code
again?...
BGB said:yeah, it is an option.
however, it is not a standard library on Windows (in certain cases, one
may need to provide for it, or expect anyone who wants to build from
source to provide for it, ...).
in my case, both often end up being the same code.
one may end up doing something initially as a learning activity, but if
one does so, and the code works fairly well, why write the same code
again?...
granted, being a programmer working for a corporation or something, vs
being an independent game developer, could also be a factor.
In science you dismiss hypothesis's based on proving them wrong
not by noting the lack of proof.
If the size of the XML file allows it then DOM and XPath is
usually the least and most readable code.
Bad day??
????
The industry standard for smartphone apps and AJAX web apps
are JSON because the bandwidth actually matters.
On 2/10/2012 12:43 PM, BGB wrote:
On 2/10/2012 9:51 AM, Lew wrote:
BGB wrote:
if one is using C, then it is either "write some code to do it", or
suffer with a 3rd party [sic] library dependency (one might validly
choose to
write the code themselves in this case).
"Suffer"? The XML parsers for C are well-established, very reliable,
and no
cause for suffering. Using a pejorative is not the same as
establishing a
point.
There is nothing wrong with the third-party libraries, and the
choice to
roll your own for C is rarely valid. You seem to suffer from NIH
syndrome.
they introduce porting hassles:
does one bundle "libxml" with their app on Windows;
do they use MSXML and then deal with having to switch over to "libxml"
when building on Linux?
LIBXML2 works fine on Windows, so you can use it on both platforms.
yeah, it is an option.
however, it is not a standard library on Windows (in certain cases, one
may need to provide for it, or expect anyone who wants to build from
source to provide for it, ...).
C is not standard on Windows either.
You need to get some things.
Because what you learn the most from and what is most cost efficient for
the company may very well be two different things.
First you spend half a newsgroup thread decrying standards and
proudly boasting how you flout them, now you suddenly denigrate a
library for not being standard?
And yes, libxml2 is, too, standard, as such things go.
"provide for it"?
So you don't write code for someone else?
Asked and answered upthread. Don't cycle.
If no one but you ever looks at your code or has to maintain it,
you can be as idiosyncratic and antisocial as you like. I know
people who've lived alone so long they cannot maintain a civil
discourse in public. Their habits don't bother them when they're
home alone, but that doesn't make them optimal.
Most of your arguments sound like apologetics for undisciplined,
egocentric programming with little connection to facts or the real
world of the workaday programmer, or the costs thereof. Heck, you
haven't even answered the question as to what the costs of software
development are.
Obtain the lock:
raf = new RandomAccessFile(file, "rw");
fo = new FileOutputStream(raf.getFD());
fo.getChannel().lock(0, Long.MAX_VALUE, false);
Release the lock:
fo.close();
yeah...
and anyways, I am not about "making conclusions" or "decreeing how
things should be done" or anything, rather, my view is there may be a
time and place for everything (and whatever is or is not the case can be
decided on a case-by-case basis or similar, based on whatever may apply
in the particular case in question, and whichever options may be cheaper
or more expensive, and similar).
IMHO, the idea that a person "should" always do things the same way in
every situation is itself arguably questionable. likewise goes for a
beliefs that something is universally required or universally
prohibited, ... ....
but, ultimately, how much something is relevant will itself tend to
depend somewhat on context.
yeah.
and, in fact 10Hz asynchronous throughput is possible... (this is
typically how most online gaming works).
one can't reasonably get 10Hz synchronous (IOW: request/response), due
to ping times, but this is a different matter.
I am not claiming one can do request/response at 10Hz, as this probably
would be impossible over a WAN (at reasonable ping times).
online gaming generally isn't based on request/response though, so the
problems of not being able to get responses at this rate don't really
matter too much (the user may still notice the results of bad ping
times, namely stuff being out of place or seemingly teleporting around
or similar, but this is a different issue).
TCP has a throughput limit due to ping, where assuming unlimited
bandwidth but a 200ms ping, one will still be limited to somewhere
around 320kB/s or so (assuming a 64kB window).
however, as is, there are typically bandwidth constraints as well (but,
they are a little more subject to fudging).
the main goal is mostly to send everything at a bandwidth low enough
that the connection doesn't risk getting backlogged (depends on internet
connection, but 16-32 kB/s seems reasonably safe, as internet radio
often tends to operate in this range, say, 192kbps is 24kB/s).
stalls are also a potential risk as well.
On 2/11/2012 12:52 PM, Arne Vajhøj wrote:
On 2/10/2012 12:43 PM, BGB wrote:
On 2/10/2012 9:51 AM, Lew wrote:
BGB wrote:
if one is using C, then it is either "write some code to do it", or
suffer with a 3rd party [sic] library dependency (one might validly
choose to
write the code themselves in this case).
"Suffer"? The XML parsers for C are well-established, very reliable,
and no
cause for suffering. Using a pejorative is not the same as
establishing a
point.
There is nothing wrong with the third-party libraries, and the
choice to
roll your own for C is rarely valid. You seem to suffer from NIH
syndrome.
they introduce porting hassles:
does one bundle "libxml" with their app on Windows;
do they use MSXML and then deal with having to switch over to "libxml"
when building on Linux?
LIBXML2 works fine on Windows, so you can use it on both platforms.
yeah, it is an option.
however, it is not a standard library on Windows (in certain cases, one
may need to provide for it, or expect anyone who wants to build from
source to provide for it, ...).
C is not standard on Windows either.
You need to get some things.
probably, but it is a question of how many things have to be worried
about as a part of getting it built (for someone wanting to rebuild from
source). if a program depends on a big pile of 3rd party libraries, it
may be harder to get rebuilt than if it doesn't.
it is arguably bad enough requiring that a particular C compiler be
installed (such as MSVC / Windows SDK), and that the program has to be
built in a certain way.
expecting the person to go download a bunch of libraries, get them
built, and put them all in the library and include paths, well, this is
adding a bit more to the cost.
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.