| |
| |
| |
|
Page: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
Comments:
<0> Jostein: it's useful for confiuguration data...not for any kind of serious searchable data storage
<1> smsie: xml is for data interchange, end of line.
<2> smsie: for data exchange, like exel said, its pretty neat
<0> yes
<0> even for data exchange, it's a bit hefty
<2> smsie: knowing XML aint a sin you know :P
<0> didn't suggest it was
<3> smsie: I'm having to consume xML produced by ADO, whihc has a toXML function on it's bloody resultset objects
<1> smsie: it's hefty and oftenly abused, but even the most braindead xml schema has advantages over the braindead binary/ascii data exchange protocols brainless companies came up with for data exchange APIs before XML.
<3> smsie: even worse, I had to write a component to -produce- such beasts as well
<2> wlfshmn: heh
<0> I use xml a fair bit...it's a handy way to move metadata around. I never see it as more than "sometimes handy"
<2> wlfshmn: ado -can- produce clean XML if the guy producing the XML has a clue :P
<0> exel: that's my beef...how many ****nuts *abuse* it
<1> I use it because interfaces I need to talk to use it.
<2> wlfshmn: or bother to put in the extra little effort
<4> RFC 3252
<1> smsie: you should see how bad non-xml 'protocols' can get if you let telco-twats design them.
<3> Jostein: no, because that format was decided upon by the -other- end guys, whom I have little controll over beyond the occational beating
<2> anyway... overly zealous use of XML is just a pain. but its better parsing XML than some arbitrary random silly format IMO
<3> Jostein: I'm atleast capable of coping with parsing xml, they did theis because it excused them from having to learn.
<2> wlfshmn: as I said. ado -can- produce sane output, if asked to. if not, you're up **** creek :P
<0> exel: I work writing middleware for the healthcare industry...believe me, I've *seen* the worst that can be done :)
<3> Jostein: doesn't help that the MSXML component is quite good at producing invalid XML
<2> if not **** creek, "lots of work" creek :P
<4> When somebody comes along who thinks that XML is THE solution to every problem, I beat them soundly about the head and shoulders with this: http://rfc.sunsite.dk/rfc/rfc3252.html
<0> exel: for very somplex data structures, xml carries a *m***ive* overhead. It's only easy to use because there are libraries ready written to do the donkeywork for you
<3> smsie: I have a friend that studies to be a nurse, and he is specilizing as an IT nurse. he is currently reading database design and java programing. that tells us a bit about the state of healthcare IT, doesn't it ;)
<2> wlfshmn: lol
<5> PolarWolf: yes given.
<0> wlfshmn: I write java most of the time these days...we're retiring the lisp
<2> wlfshmn: #define invalid?
<5> wlfshmn: no, I won't fry my nads on the crt.
<0> Jostein: haha, not seen that one before
<3> Jostein: for example, it likes to stick \0's into CTEXT
<1> smsie: yeah. Since I wrote the parser, I'm painfully aware of parsing overhead. But since most of my software is about communicating with other people's software over a tcp link, XML is more sensible then going roll-your-own.
<2> wlfshmn: it does? thats crap
<3> Jostein: or rather, it doens't handle low ascii in CTEXT at all
<2> smsie: sorry :P
<3> Jostein: but it's the nulls you run into
<2> wlfshmn: you trying to send binary over XML or what? :P
<0> exel: no, it's really not. Over a slow tcp link it's a BAD idea
<3> Jostein: it could be fine if it encoded them as entities, as it's supposed to, but it doesnt
<1> smsie: depends on the transaction count. And I wasn't saying "slow tcp link".
<0> exel: over fast links it's not terrible, but the parsing overhead is fairly heavy...livable with though
<2> wlfshmn: I gotta try that at work tomorrow. too lazy right now
<3> Jostein: nah, we do text only, but occationally you find null characters in text as well, pasting from one place or another into the text fields
<2> wlfshmn: but I thought that in CDATA anything was ok? that you only used entities -outside-- CDATA. That was the whole point of CDATA, right?
<0> exel: I routinely deal with sending data over 64k lines...around 10k transactions per day. Pipe delimited, they are about 4k each. If I xmled them up, they'd be 3 times that at least :)
<1> smsie: generally, there is much more work to be done _with_ the data then you're spending on the parsing side.
<6> smsie: The advantage of using xml for transactions over a network link is that its' very easy to make kits of software speak the same dialect
<2> smsie: http-gzip is your friend :P
<6> smsie: At least that's the theory. It's a bit of a bummer there are so many "standard" dialects for systems to speak xml with eachother :)
<3> bjindeed, this is C-text- though, ie, the regular character encoding
<2> smsie: it will reduce UTF-16 encoding to half the data *grin*
<0> PolarWolf: I don't *want* bits of software speaking the same language dammit! I get PAID to write the software that translates all the different languages they speak! :)
<6> smsie: Hehe
<3> Jostein: in CDATA it would be fine as well, I think, but I havnt' got the spec near me
<6> smsie: Hey, at least the marketing sounds cool :P
<7> heh
<0> that's mainly what it is...marketting
<6> smsie: Guys like you are hired because the products don't actually live up to the marketing hype
<2> wlfshmn: as far as I "get" XML the point of CDATA is to avoid all the standard XML restrictions, so you dont have to do overzealous entity-transformations
<0> you can market pig**** as "porcine manure". Doesn't make it not-pig**** :)
<1> ok I'm off doing some color correction
<2> wlfshmn: but as far as MSXML goes.. they have written the wrong CDATA definition in the manuals :P
<6> smsie: Yeah, but at least it's still pig****. What I hate is receiving pig**** while I was told I'd get horsedung :)
<0> fair comment
<2> PolarWolf++
<7> Yeah, but if it weren't for strong marketing, Compaq and Dell would have crumbled years ago. Managers love their pig**** when it's got a "big name" stamped on it, and they're the buyers.
<3> Jostein: yes, I think that in cdata the only restrictions are the end-cdata section ;)
<0> CeruleanD: Dell actually have a pretty viable model these days. Compaq are still Compaq of course...
<6> CDATA means "gee, this is crap we don't know how to structure"
<7> Their business model is good. Their hardware is still ****. :)
<0> the XML equivalent of BLOB/CLOB then...
<2> wlfshmn: so I dunno. while \0 doesnt belong anywhere in my books, it's technically not -invalid-
<0> CeruleanD: but it's *cheap* ****. It *used* to be overpriced ****, and it was hurting them...now it's cheap **** and everyone is buying it
<3> smsie: well, clob and blob are basically a matter of "you wanst rows to be -how- long? Screw that!"
<7> That's true
<6> It gets funny when you see message brokers which spit out globs of xml which have four XML tags about who they are, and the rest of the message is implemented as CDATA
<6> That means someone found the wrong tool for the job
<3> Jostein: \0 is invalid in CTEXT, not in CDATA
<7> I admit, I bought their 24" LCD and I'm relatively impressed with the $1,250 pricetag that included a P4 system
<2> wlfshmn: ah. sorry. read that wrong :P
<8> PolarWolf: or the right hype ;)
<6> Lion-O: Hmm, point
<3> PolarWolf: lot's of people cludge text into cdata sections to get around the "problem" that xml trashed CRLf
<0> there was a time you could self-build significantly better/cheaper than you could buy prebuilt. That's just not true any more. If you want something special it still is, but for standard kit...
<3> PolarWolf: the path of least resistance is often to just put the stuff in a black plastic bag, after all
<6> wlfshmn: XML is all about structured data...why use XML while the data can't be structured?
<0> PolarWolf: because it's *XML*
<6> smsie: Hrm :)
<0> because hte manglers will be ****ing *impressed*!
<2> wlfshmn: CRLF ****s anyway. Should just be CR :P
<3> PolarWolf: XML is a checkmark on the feature list
<6> Just send the crap in base64
<2> wlfshmn: why the hell keep up with typewriter/dot-matrix printer definitions these days? :P
<2> smsie: ^^ you as well
<3> PolarWolf: somewhere in a spec somewhere it probably sais generically that "inter process communication MUST be accomplished in XML"
<8> PolarWolf: so far the lamest example I've heard so far in casus "html vs. xml" was that xml is easier for your software to grok.
<6> wlfshmn: I wouldn't be at all surprised :)
<2> wlfshmn: I love how people who "uses" xml, but only contains the same old flatfile in XML-tags :P
<0> even when it makes less sense than a chocolate coffee mug
<2> wlfshmn: That just shows a level of competency I can only dream of ever achiving *grin*
<3> PolarWolf: The worst thing in the world is when we get a spec or RFQ written largely by an uknowledgeable techie
<0> wlfshmn: I send those back
<3> PolarWolf: such things always ask irrelevant and pointless questions about our choice of technology and ignore if the product actually -works- or not
<0> wlfshmn: I tell those to go away and stop wasting my time (well, I have a manager to do that for me, politely)
<7> heh
<8> hmm :)
<7> Managers *do* have their uses now and then
<0> good ones do, certainly
<3> smsie: hehe, I used to have am ansager that did that and understood his function in the world
<9> 'javac' compiles java source code into JVM machine code. Can I compile java source code into a linux binary?
<3> smsie: my current manager is a sales person though
<3> smsie: reasonably clued sales person, admittedly, but a sales person none the less
<0> Muir: yes
<8> Muir: there are some compilers which can "sorta" do that, usually its a waste of time. Just wrap a shellscript around it.
<2> Muir: why would you want to do that?
<2> Muir: wruite highlevel code then ditch every advantage that semi-bloated code has for a binary thats just as bloated?
<6> wlfshmn: Get out of the business software market and become a systems programmer instead :P
<0> it's not *every* advantage
<0> not even most of them
<9> I watn to write a simple program to configuire some parameters which are needed for a thin client i built, and im taking a java cl*** at a university, so this way i would only have to learn java and not C++
<0> about all you lose is the security manager
<8> Muir: rofl, forget about that idea.
<0> not that the code is any faster
<2> smsie: you do lose platform independecy
<8> Muir: Java isn't C++ and the other way around also goes. You can't substitute one for the other by the use of a mere compiler.
<0> Jostein: that's not as much of anadvantage as people think
<9> well I think for this simple program it will suffice
<0> it's a bull**** advantage in fact
<9> whats rofl ?
<8> Muir: very dumb idea if you ask me. Alas; search the java newbie forums, plenty of that stuff available.
<3> Muir: if you make technical decisions based on how much you have to learn, you need to reconsider your career path
<8> Muir: "rolling over the floor, laughing"
<2> smsie: I dont mind being able to just -copy- software to my phone :P
<9> hahaha
<8> wlfshmn++
<9> rofl
<2> wlfshmn++
<3> Muir: You always use the right tool for the job. if you don't know how to use that tool, you learn how to do it. If you dfon't have time to, you work 16h/day ;)
<2> wlfshmn: are you advocating -effort- in here? :P
<8> wlfshmn: but hey, don't you know how it works in the modern days? You don't learn how to program, you get tools to do it for you and the rest is asked on several channels untill someone spoonfeeds you the answers :P
<3> Jostein: I'm not saying laziness isn't a virtue, but laziness has to be applied with wisdom, or it stop beeing laziness and moves into the area of stupidity
Return to
#linux
or
Go to some related
logs:
#AllNiteCafe
#apache
#linuxhelp
The Horrorist - One Night In New York City (Viper XXL vs Dj Amok Mix)
#AllNiteCafe
kiprea
ultlmate key
backward bit c++
#mirc
#linuxhelp
|
|