• JavaCoder (unregistered)

    The real WTF is that it is -128 to +127.

  • (cs)

    I suppose it all depends upon how many bits you have in your bytes. Personally, I always overdesign a bit (pun intended) and use 9 bits. Problem solved!

  • (cs)

    It is puzzling how an attachment (image, in this case) could be -45 bytes long. Does it 'leech' data from other files around it?

  • NThenUDie (unregistered)

    The real WTF is that someone managed to take what was probably a simple character stream protocol, wrap it in unhelpful XML, declare it enterprise compliant and then collect a bonus or promotion. Nice job!

  • (cs) in reply to snoofle
    snoofle:
    I suppose it all depends upon how many bits you have in your bytes. Personally, I always overdesign a bit (pun intended) and use 9 bits. Problem solved!

    The wording of this was kinda funny. Overdesign a bit ! You must be using 3 way bits :)

  • (cs)

    So much for enterprisey software, it can't even do data validation on the XML !

  • Frank Butcher (unregistered) in reply to JavaCoder
    JavaCoder:
    The real WTF is that it is -128 to +127.
    Please tell me this is a joke taking the piss out of java coders....
  • Bob (unregistered)

    Image data! Wtf?

  • Edward Royce (unregistered)

    Hmmmm.

    "<bytes>37</bytes>"

    Are you telling me that your library is wrapping a "<bytes>" + "</bytes>" tag pair around each and every singl byte of image data??

    Doesn't that blow up image sizes by 16? A 10k would become 160k. Isn't that a little ridiculous?

  • Will (unregistered) in reply to Edward Royce
    Edward Royce:
    Doesn't that blow up image sizes by 16? A 10k would become 160k. Isn't that a little ridiculous?

    He said it was enterprisy didn't he...

  • (cs) in reply to Edward Royce
    Edward Royce:
    Hmmmm.

    "<bytes>37</bytes>"

    Are you telling me that your library is wrapping a "<bytes>" + "</bytes>" tag pair around each and every singl byte of image data??

    Doesn't that blow up image sizes by 16? A 10k would become 160k. Isn't that a little ridiculous?

    Oh... My... God... Really looks that way! :|

  • tag (unregistered) in reply to Edward Royce
    Doesn't that blow up image sizes by 16? A 10k would become 160k. Isn't that a little ridiculous?

    Try saving as BMP uncompressed. THAT is ridiculous.

  • Adrian (unregistered)

    After reading this column since nears its begining - thought i was getting immune to stupidity of programmers.....

    once again i find my self thinking 'OMG did the programmer have any idea of what s/he was doing?'

  • draeath (unregistered) in reply to CrazyBomber

    Hopefully the xml is gzipped on-the-fly. We can only hope.

  • (cs)

    The real WTF is that the <bytes> tag only contains a single byte....it should be <byte>. </rants>

  • Chucara (unregistered)

    Wow.. I had no idea XML could be this useful. Now you can use any random text editor instead of photoshop! Excellent solution once you fix the bug. Again, that would be easy to do with an XML editor. Brilliant!

  • JavaCoder (unregistered) in reply to Frank Butcher
    Frank Butcher:
    JavaCoder:
    The real WTF is that it is -128 to +127.
    Please tell me this is a joke taking the piss out of java coders....

    Two's complement is not a joke.

  • (cs) in reply to Edward Royce
    Edward Royce:
    Are you telling me that your library is wrapping a "<bytes>" + "</bytes>" tag pair around each and every singl *byte* of image data??
    There is one way to fix this problem. Convert each of those to something like this (with namespaces omitted for brevity): 
    <bytes>
    <bit number="0" lsb="true">1</bit>
    <bit number="2">1</bit>
    <bit number="5">1</bit>
    <bit default="true">0</bit>
</bytes>

    By doing this, you eliminate the interoperability problem of just how to represent bytes and instead have something that is easy to interpret unambiguously every time!!

  • (cs) in reply to pitchingchris
    pitchingchris:
    snoofle:
    I suppose it all depends upon how many bits you have in your bytes. Personally, I always overdesign a bit (pun intended) and use 9 bits. Problem solved!

    The wording of this was kinda funny. Overdesign a bit ! You must be using 3 way bits :)

    This forum has featured numerous articles on state x>2 booleans, and of course, the original

  • cthulhu (unregistered)

    Another problem with this technique is that bytes alone mean nothing to most people and you can't tell the dimensions of the image. A better solution would probably be:

    <Row> <pixel>Green</pixel> <pixel>Yellow</pixel> <pixel>Red</pixel> </Row>

    There are many standardized color charts that could be utilized that I believe cover all possible real-life colors, eg:

    <pixel>Sunset Orange</pixel> <pixel>Light Green</pixel> <pixel>Reddish</pixel> <pixel>Lime Green</pixel> <pixel>Sea Breeze Blue</pixel> <pixel>Woodchip Brown</pixel>

    This way the underlying encoding for images could be understood by anyone. This might be a worthwhile project for anyone with sufficient XML skills.

  • Tobias (unregistered)

    I bet somewhere deep in the code there is a loop over all the bytes of the image data that looks like this:

    public String toXML(ByteIterator bIt) {
    StringBuilder sb = new StringBuilder("<attachments xmlns=...>");
    while(bIt.hasNext()) {
        sb.append("<bytes>");
        sb.append(toHexString(bIt.next()));
        sb.append("</bytes>");
    }
    sb.append("</attachments>");

    return sb.toString();
}

    But more probably it is done by String-concatenation with "+" for performance reasons (Don't have to instantiate this crappy StringBuilder etc) ...

    kind regards Tobias

  • The_Assimilator (unregistered)

    The goggles, they cannot stop the bleeding from my eyes!

    Seriously, the developer who wrote that serialization "code" should be forced to print it out and eat it. Matt, please tell me you fired that guy on the spot...

  • Anonymous (unregistered) in reply to tag
    tag:
    Doesn't that blow up image sizes by 16? Isn't that a little ridiculous?
    Try saving as BMP uncompressed. THAT is ridiculous.
    Well, you can always use PNG at 64 bit per pixel with compression turned off...
  • Enterpriser (unregistered)

    This code is horrible. Even if the app was expecting numbers in the range 0-255, COMPUTERS ARE NOT MAGICIANS. How are they supposed to know what such generic numbers are representative of. If this was using a real enterprise approach it would be:

    <attachments xmlns = "http://webservices..." > <bytes> <integer prime="true"> <positive> <odd>37</odd> </positive> </integer> </bytes> <bytes> <integer prime="false"> <positive> <even>80</even> </positive> </integer> </bytes> ...

    and if I knew how to format with this thing, you would even be able to read it!

  • (cs)

    The real WTF is that it appears a byte is stored in an element called "bytes"... :-/

    Enterpriser:
    ...and if I knew how to format with this thing, you would even be able to read it!
    There are [code][/code] tags, but they add extra line breaks...
  • (cs) in reply to Edward Royce
    Edward Royce:
    Hmmmm.

    "<bytes>37</bytes>"

    Are you telling me that your library is wrapping a "<bytes>" + "</bytes>" tag pair around each and every singl byte of image data??

    Doesn't that blow up image sizes by 16? A 10k would become 160k. Isn't that a little ridiculous?

    Well it's worse than that. Those bytes are being written out as 1 to 3 digits of ASCII, with an optional negative sign. 160k would be your best case scenario and only applicable if the bytes were between 0 and 9. Worst case scenario would be 200k though, so not much more....

    These guys should totally do an efficiency enhancement feature to make the thing smaller by putting it in signed hex format (-80 through 79). That way you potentially save one byte per byte...at least until your local standards nazi comes and deems that the values be written as -0x80 through 0x79....

  • mauhiz (unregistered)
    <comment xmlns = "http://thedailywtf..." > <bytes>79</bytes> <bytes>77</bytes> <bytes>71</bytes> ...
  • Morten (unregistered)

    Enterprise Heaven! This is why god invented HPC's!!

    My God, even I know how to use Base64 strings for straight out of the box Xml serialization of binary files...

  • (cs) in reply to Morten

    The Real WTF is only hinted at here. The fix was, of course, to write a "BytesConverter class" that parses the XML, adds 128 to each element, then writes it back into XML to be consumed by the client.

    Seriously though, I have a feeling this is actually the 2nd implementation of the Web Service. The first implementation was the sane one where the content type is set as image/jpg and an image is returned. The CTO then steps in, says "This is not Enterprisy enough! It doesn't fit in with our framework!" Then the junior dev goes back to square one and this monstrosity is the result.

  • (cs) in reply to Edward Royce

    TRWTF is that XML contains a perfectly reasonable way to specify arbitrary chunks of binary data. It does not involve wrapping every single byte in its own tag. Base64 encoding is perfectly nice too.

    But why follow a standard when you can make up your own half-assed way? Then when it breaks, you never know who to blame because nobody knows what the right way is.

  • hacketihackhack (unregistered) in reply to Edward Royce

    Yeah it is rediciolus. Why not just base64-encode the thing and wrap it in a tag?

    But OTH gzipping it at transport level wouldn't make it THAT much bigger, since the byte tags are all the same.

  • hacketihackhack (unregistered) in reply to Enterpriser

    Oh I love the redundancy of that one!

  • TwelveBaud (unregistered) in reply to Chucara
    Chucara:
    Wow.. I had no idea XML could be this useful. Now you can use any random text editor instead of photoshop! Excellent solution once you fix the bug. Again, that would be easy to do with an XML editor. Brillant!
    fixed. :P
  • bold (unregistered)

    Remembering that XML's golden selling point is "human readable", image expression should be more like this:

    <image scale="(about yay big)"> <background> <color-palette class="sunsetty"><not-too value="orange"><possibly-some-kind-of type="clouds" class="whispy"/></not-too> </background> <overlay origin="(in the middle(left a bit))"> <sort-of a="dog"><with a="tail"><but more-like="ref:horse"/></with></sort-of> </overlay> <paint-brush style="wooden-handled"> <set id="horse" merge="(closing one eye hold up your thumb)" canvas="linen"> <paint style="jackson-pollock"/> <paint style="something nice"/> </set> <paint inspiration="shetland pony"/> </paint-brush> </image>
  • (cs) in reply to cthulhu
    cthulhu:
    Another problem with this technique is that bytes alone mean nothing to most people and you can't tell the dimensions of the image. A better solution would probably be: <Row> <pixel>Green</pixel> <pixel>Yellow</pixel> <pixel>Red</pixel> </Row>

    There are many standardized color charts that could be utilized that I believe cover all possible real-life colors, eg:

    <pixel>Sunset Orange</pixel> <pixel>Light Green</pixel> <pixel>Reddish</pixel> <pixel>Lime Green</pixel> <pixel>Sea Breeze Blue</pixel> <pixel>Woodchip Brown</pixel>

    This way the underlying encoding for images could be understood by anyone. This might be a worthwhile project for anyone with sufficient XML skills.

    I don't know if this is meant to be serious or not... I'm no XML expert (or fan), but I think that "entity references" (if I'm thinking of the right thing) would be more efficient and reliable than string colors.

    <!-- You could also probably just define the integer value instead of the string. Whatever. -->
<!ENTITY sunset-orange PUBLIC "Sunset Orange">
<!ENTITY light-green PUBLIC "Light Green">
<!ENTITY reddish PUBLIC "Reddish">
<!ENTITY lime-green PUBLIC "Lime Green">
<!ENTITY sea-breeze-blue PUBLIC "Sea Breeze Blue">
<!ENTITY woodchip-brown PUBLIC "Woodchip Brown">
(etc...)
    <pixel>&sunset-orange;</pixel>
<pixel>&light-green;</pixel>
<pixel>&reddish;</pixel>
<pixel>&lime-green;</pixel>
<pixel>&sea-breeze-blue;</pixel>
<pixel>&woodchip-brown;</pixel>

    Assuming that an error would be thrown if the reference didn't exist (i.e. typed the wrong name). For the record, I've only taken a single XML class (which I hated) and haven't really used it since so I could be completely wrong. =P Again, I'm no fan of XML.

  • luptatum (unregistered) in reply to Edward Royce

    Just converting a byte array to a string will double the size... If you have one byte 0xFF.ToString("X") == "FF" as a string which is two bytes long (in ASCII and excluding other encoding types) WTF! Why oh why do people do these things?!?!

    [quote user="cthulhu"]This way the underlying encoding for images could be understood by anyone. This might be a worthwhile project for anyone with sufficient XML skills[/quote] plz send teh codz!!!

    If you build it, someone will buy and use it...

    [quote user="Tobias"]ut more probably it is done by String-concatenation with "+" for performance reasons (Don't have to instantiate this crappy StringBuilder etc) ... [/quote[ heh as you said, the real wtf for the people who write this crap is this string builder waste of programming cycles you write about...

  • Chandler (unregistered) in reply to cthulhu

    I am thoroughly inspired. This may have to become a side proejct for me.

  • (cs) in reply to luptatum
    luptatum:
    Tobias:
    ut more probably it is done by String-concatenation with "+" for performance reasons (Don't have to instantiate this crappy StringBuilder etc) ...
    heh as you said, the real wtf for the people who write this crap is this string builder waste of programming cycles you write about...
    I may be missing the sarcasm here, but using + for String concatenation in Java is just a shorthand for creating a new StringBuilder, combining all the strings in the line, and then returning the resulting String. This means that at best, with excellent compiler optimisation, you would get the same performance as using StringBuilder manually, and most likely the performance would be worse. In my copious free time I may get around to testing this, but I doubt I will have time in the near future.

    Addendum (2008-04-30 10:47):

    luptatum:
    Tobias:
    ut more probably it is done by String-concatenation with "+" for performance reasons (Don't have to instantiate this crappy StringBuilder etc) ...
    heh as you said, the real wtf for the people who write this crap is this string builder waste of programming cycles you write about...
    I may be missing the sarcasm here, but using + for String concatenation in Java is just a shorthand for creating a new StringBuilder, combining all the strings in the line, and then returning the resulting String. This means that at best, with excellent compiler optimisation, you would get the same performance as using StringBuilder manually, and most likely the performance would be worse. In my copious free time I may get around to testing this, but I doubt I will have time in the near future.

    EDIT: Even the complete WTF which is the emacs image editor uses a saner format for image data.

    (an even bigger WTF is the emacs video editor(http://1010.co.uk/gneve.html), which is almost as crazy as SSDS, except that the commands make sense and it actually does something useful)

  • Merlin (unregistered) in reply to Edward Royce
    Edward Royce:
    Hmmmm.

    "<bytes>37</bytes>"

    Are you telling me that your library is wrapping a "<bytes>" + "</bytes>" tag pair around each and every singl byte of image data??

    Doesn't that blow up image sizes by 16? A 10k would become 160k. Isn't that a little ridiculous?

    It's even nicer if you try loading the XML-Document into a .NET XMLDocument. The parsed structure will have a memory footprint that could scale up to 10 times the string size.

  • Anonymous (unregistered) in reply to Physics Phil
    Physics Phil:
    I may be missing the sarcasm here
    Yes.
  • xmlicious (unregistered)

    XML is like violence: if it doesn't solve your problem, you're not using enough of it.

  • (cs)

    This isn't retarded enough for my taste. How about:

    <image>
  <pixel>
    <row>0</row>
    <col>0</col>
    <color>#CF00D9</color>
   </pixel>
  ...
  <pixel>
    <row>999</row>
    <col>99</col>
    <color>#00FF00</color>
  </pixel>  
</image>

    That's more like it!

  • larry (unregistered)

    BTW, it's from -128 to 127 in two's complement systems, and that's usually how you see bytes signed unless they did something for extra weirdness. </dweeb>

  • (cs) in reply to cthulhu
    cthulhu:
    <pixel>Reddish</pixel>
    You make me smile.
  • Steve (unregistered)

    Regarding the 0 - 255 vs -128 - 127 conundrum, I've been programming in Java seriously for about five or six years (after about 15 or so years in C, starting with classic K&R and progressing to ANSI C when it became prevalent) and like the language a lot.

    But since I have to deal with raw image data (and I mean RAW, as it comes off imaging devices in some strange format only an engineer could love), the designer's choice to not include unsigned data types, particularly unsigned byte, makes me want to scream sometimes.

    I've never understood why that was necessary.

    As for the XML, I'm afraid some of my early efforts looked like that.

    I'm better now.

    Slightly.

  • Anon (unregistered) in reply to Physics Phil
    Physics Phil:
    luptatum:
    Tobias:
    ut more probably it is done by String-concatenation with "+" for performance reasons (Don't have to instantiate this crappy StringBuilder etc) ...
    heh as you said, the real wtf for the people who write this crap is this string builder waste of programming cycles you write about...
    I may be missing the sarcasm here, but using + for String concatenation in Java is just a shorthand for creating a new StringBuilder, combining all the strings in the line, and then returning the resulting String. This means that at best, with excellent compiler optimisation, you would get the same performance as using StringBuilder manually, and most likely the performance would be worse. In my copious free time I may get around to testing this, but I doubt I will have time in the near future.

    Oh dear.

    Java (and .Net) Strings are immutable.

    If you are using 

    s += "new string";
    in a loop you aren't appending to an existing String, you are creating a new String each time, leaving behind a bunch of unreachable Strings to be garbage collected.

    String s = "";
for (int i = 0; i < 100; ++i) {
    s += "xx";
}

    The above code creates 100 String objects... the first contains "", the second contains "xx", the third contains "xxxx", etc. Of those, the only String that remains reachable after the loop completes is the String object containing 200 'x' characters. The above loop has created String objects containing 9900 characters, none of which are reachable when the loop ends, all of which have to be garbage collected.

    StringBuilder sb = new StringBuilder("");
for (int i = 0; i < 100; ++i) {
    sb.append("xx");
}
Strings s = sb.toString();

    The above code on the other hand creates a single StringBuilder which contains 200 characters to be garbage collected.

    Obviously a loop of 100 iterations appending two characters isn't that big a deal, but try a loop of 1000 iterations appending four characters... 1998000 characters in 1000 unreachable Strings have to be garbage collected.

    I can't believe this had to actually be explained to anyone.

    Explained again at http://java.sun.com/developer/JDCTechTips/2002/tt0305.html

  • (cs) in reply to DropDeadThread
    DropDeadThread:
    This isn't retarded enough for my taste. How about: 
    <image>
  <pixel>
    <row>0</row>
    <col>0</col>
    <color>#CF00D9</color>
   </pixel>
  ...
  <pixel>
    <row>999</row>
    <col>99</col>
    <color>#00FF00</color>
  </pixel>  
</image>
    That's more like it!

    Not so fast there chief. What if we want to use a greater color depth in the future? And how will a human reading this know whether the rows and columns are measured from the top left, bottom left, etc? What if we want to make it 3D?

    <pixel>
    <euclideanCoordinates>
        <origin>center</origin>
        <row>-150</row>
        <col>-300</col>
        <z>0</z>
    </euclideanCoordinates> 
    <color>
         <red>0x00</red>
         <green>0xFF</green>
         <blue>0x00</blue>
    </color>
</pixel>
<pixel>
    <polarCoordinates>
        <degrees>90</degrees>
        <dist>4</dist>
    </polarCoordinates>
    <color>
         <red>0x0000</red>
         <green>0x0000</green>
         <blue>0xFF00</blue>
    </color>
</pixel>

    Now that's an Enterprise Business Solution.

  • NaN (unregistered) in reply to Outlaw Programmer
    Outlaw Programmer:
    The Real WTF is only hinted at here. The fix was, of course, to write a "BytesConverter class" that parses the XML, adds 128 to each element, then writes it back into XML to be consumed by the client.

    The Real WTF is that there are programmers who do not know about two's complement.

  • mister (unregistered) in reply to vt_mruhlin
    vt_mruhlin:
    Not so fast there chief. What if we want to use a greater color depth in the future? And how will a human reading this know whether the rows and columns are measured from the top left, bottom left, etc? What if we want to make it 3D?
    ---snip---
    Now that's an Enterprise Business Solution.
    What? And limit yourself to rgb colors? No transparency? This is how it should be done: 
    <pixel>
    <euclideanCoordinates>
        <origin>top-left</origin>
        <row>-150</row>
        <col>-300</col>
        <z>0</z>
    </euclideanCoordinates> 
    <rgbColor>
         <red>0x00</red>
         <green>0xFF</green>
         <blue>0x00</blue>
         <alpha>1.0</alpha>
    </rgbColor>
</pixel>
<pixel>
    <polarCoordinates>
        <origin>center</origin>
        <degrees>90</degrees>
        <dist>4</dist>
        <z>0</z>
    </polarCoordinates>
    <cmykColor>
         <cyan>0x0000</cyan>
         <magenta>0x0000</magenta>
         <yellow>0xFF00</yellow>
         <black>0x00FF</black>
         <alpha>0.5</alpha>
    </cmykColor>
</pixel>
<pixel>
    <sphericalCoordinates>
        <origin>bottom-right</origin>
        <zenith>60</zenith>
        <azimuth>30</azimuth>
        <dist>5</dist>
        <z>2</z>
    </sphericalCoordinates>
    <rybColor>
         <red>0xFFFF</red>
         <yellow>0x0000</yellow>
         <blue>0x00FF</blue>
         <alpha>0.75</alpha>
    </rybColor>
</pixel>
  • t saint (unregistered)

    This looks to me like the provider was using Apache Axis or some similar toolkit. IIR the Axis implementation does this with byte arrays if you use the wrapped style. Thing is that if you use the RPC style then multirefs are implemented which some security appliances don't really like.

Leave a comment on “Oh, XML”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article