The ESBESB



  • Another development team is responsible for our ESB. They aren't particularly good at figuring out how things should work, so folks tend to avoid using the ESB - not because it won't/can't do the job, but because writing software in tandem with the ESB team is just too painful.

    Someone got the bright idea that they could build a tool to receive messages from a myriad of sources, optionally pass data to web services, and pass data on to subscribing interested third parties in addition to returning data to the original caller. It took a while, but it got hodge-podged together and sort of worked.

    Then someone got the bright idea that a lot of the message handling/routing/pub-sub functionality of the ESBESB was already built into the underlying ESB, and so the ESBESB was refactored to do a lot of its work by delegating it to the underlying ESB. In other words, task A publishes a message to the ESBESB which delegates the receipt of that message to the ESB which returns it to the ESBESB, which then delegates the handling of the message to the ESB which returns the result to the ESBESB, which then itself manages which messages are to be forwarded to which interested subscribers, and delegates forwarding a given message to one party to the underlying ESB.

    Naturally, all this delegation takes time and causes all sorts of context switches, allocation/deallocation of storage, network hits, etc. All the messages are passed via persistent messages, so every message push involves a network disk write, and every message pull involves deleting the persisted message from the disk backing the queue.

    Then people start complaining that there are performance problems, and they dump the whole thing in my lap to fix. I wrote a scathing report detailing the multiple levels of WTF and sent it up the chain. The C** executives don't want to hear it: "Just fix it!". Um no, you recently put out a directive that no unscheduled projects are to be undertaken; no exceptions. We are supposed to stick to the assigned work and not deviate unless senior brass changes priorities. Are you changing the priorities? "No." Ok, then this can sit a while. Perhaps you should consider performance and engineering reviews before allowing junior folks to undertake any new software development efforts in the future.

    Sigh.

     



  • You're not a team player.



  • I have no idea what ESB stands for. So I'll look it up.

    ESB:

    1. Star Wars (Empire Stikes Back)
    2. Eat shit Bitch
    3. ESB stands for Estradiol Soaked Bitch. It describes a woman with a symmetrical face and a slender hourglass figure who is very confident, selfish and narcissistic. She often betrays other women by stealing their mates and is usually only popular with brain dead men.
    4. An ancronym for Excessive Sperm Build-up (aka Blue Balls).
    5. E ast S ide B oys... a street gang in eastside Kansas City. Rival to the Brookside W est S ide B itchy B oys.... ESB territory is from east 51st St. to east 59th St. 3 main Gang leaders live in the middle of he turf around Brookside Park
    6. Enormous Sperm Builtup
    7. A street gang in the Bowling Green area of Eastside Kansas City, MO. The gang is notorious for dealing cocaine and gang-bangin. The gang color is red. ESB's are in alliance with the Trae Side Poppas, another BG Gang. Rival gangs are Kemp Spillas and 62's, westside gangs. The ESBs, or E ast S ide B loods (B oyz), out number the Spillas and 62's throughout Kansas City on Jackson County.
    8. East Side Brotherhood. One of the small gangs in Richmond consisting of a few Canadians, filipinos and other asians

    In conclusion, WHAT THE FUCK DOES ESB STAND FOR?



  • @Ben L. said:

    I have no idea what ESB stands for. So I'll look it up.

    Given context, I'm going to guess something like Enterprise Service Bus

    As a side note, TRWTF is Urban Dictionary



  • @electronerd said:

    @Ben L. said:
    I have no idea what ESB stands for. So I'll look it up.

    Given context, I'm going to guess something like Enterprise Service Bus

    As a side note, TRWTF is Urban Dictionary

    So ESB means the same thing as API and RPC?

    "A thing that other things delegate work to."



  • @Ben L. said:

    @electronerd said:
    @Ben L. said:
    I have no idea what ESB stands for. So I'll look it up.

    Given context, I'm going to guess something like Enterprise Service Bus

    As a side note, TRWTF is Urban Dictionary

    So ESB means the same thing as API and RPC?

    "A thing that other things delegate work to."

    Worse. It means a SOA implementation that relies on a canonical data model and on service contracts with explicit governance rules agreed upon by all the relevant stakeholders.



  • @Ronald said:

    @Ben L. said:
    @electronerd said:
    @Ben L. said:
    I have no idea what ESB stands for. So I'll look it up.

    Given context, I'm going to guess something like Enterprise Service Bus

    As a side note, TRWTF is Urban Dictionary

    So ESB means the same thing as API and RPC?

    "A thing that other things delegate work to."

    Worse. It means a SOA implementation that relies on a canonical data model and on service contracts with explicit governance rules agreed upon by all the relevant stakeholders.

    WHAT THE FUCK DOES SOA STAND FOR?

    Okay, calm down Ben. Let's check Urban Dictionary.

    1. n. In computing, a Service-Oriented Architecture (SOA) is a flexible set of design principles used during the phases of systems development and integration. A deployed SOA-based architecture will provide a loosely-integrated suite of services that can be used within multiple business domains.
    

    SOA also generally provides a way for consumers of services, such as web-based applications, to be aware of available SOA-based services. For example, several disparate departments within a company may develop and deploy SOA services in different implementation languages; their respective clients will benefit from a well understood, well defined interface to access them. XML is commonly used for interfacing with SOA services, though this is not required.

    Service-orientation requires loose coupling of services with operating systems, and other technologies that underlie applications. SOA separates functions into distinct units, or services, which developers make accessible over a network in order to allow users to combine and reuse them in the production of applications. These services and their corresponding consumers communicate with each other by passing data in a well-defined, shared format, or by coordinating an activity between two or more services.

    oh.



  • @Ben L. said:

    WHAT THE FUCK DOES SOA STAND FOR?

    I figured ESB, and especially SOA, were pretty well-known acronyms.



  •  Is TRWTF that you don't know what ESB or SOA are, or that you try and look them up on Urban Dictionary instead of say, Google or Wikipedia?

    I smell a troll.



  • @pbean said:

     Is TRWTF that you don't know what ESB or SOA are, or that you try and look them up on Urban Dictionary instead of say, Google or Wikipedia?
    Or the usually-reliable "serious" cousin of Urban Dictionary, AcronymFinder.

    Where the only five-star expansion is The Empire Strikes Back, the only four-star is École Supérieure du Bois (French wood processing school), and the three-star offerings are:

    Erdgas Südbayem GMBh (a Munich gas utility), Encefalopatía Spongiforme Bovina (the Spanish name for mad-cow disease), Extra Strong Bitter (a type of beer), Enhanced Separate Brigade (no idea what this is), the airport code for Esenboga in Ankara, and the Engineering Society of Buffalo (which probably infects Spanish cows).



  • @morbiuswilters said:

    @Ben L. said:
    WHAT THE FUCK DOES SOA STAND FOR?

    I figured ESB, and especially SOA, were pretty well-known acronyms.

    Among people who work with Oracle and Java bullshit maybe. I've never heard ESB in my career.

    I hate to agree with Ben L, but if you're willing to spent hundreds of words communicating with people maybe actually ensure they know what the fuck you're talking about at some point. Snoofle's usually pretty good about this, not sure what went wrong here.



  • @blakeyrat said:

    Among people who work with Oracle and Java bullshit maybe. I've never heard ESB in my career.

    To be honest, I'm not sure I had either. I pretty much pulled "Enterprise Service Bus" out of my ass and was just lucky to have come up with a real term.



  • @blakeyrat said:

    @morbiuswilters said:
    @Ben L. said:
    WHAT THE FUCK DOES SOA STAND FOR?

    I figured ESB, and especially SOA, were pretty well-known acronyms.

    Among people who work with Oracle and Java bullshit maybe. I've never heard ESB in my career.

    I hate to agree with Ben L, but if you're willing to spent hundreds of words communicating with people maybe actually ensure they know what the fuck you're talking about at some point. Snoofle's usually pretty good about this, not sure what went wrong here.

    I come across ESB relativley often but then one of our dev teams specifically writes integrations for third parties, some of whom (a tiny minority) use an ESB

    If you've heard of / come across WebSphere MQ, RabbitMQ or even Biztalk, then these are ESBs

    Having said all of that, it was "The Next Big Thing" in the mid noughties but rightly died a death for the reasons mentioned by snoofle and Ronald - that it becomes unmanageable and ultra-expensive trying to connect everything to everything


  • Discourse touched me in a no-no place

    @blakeyrat said:

    I've never heard ESB in my career.
    Some people have all the luck.



  • @pbean said:

     Is TRWTF that you don't know what ESB or SOA are, or that you try and look them up on Urban Dictionary instead of say, Google or Wikipedia?

    I smell a troll.

    No, TRWTF was that you've turned your volume down so low you missed the distinctive whooshing sounds coming out of Ben's posts.



  • If you've ever worked with "enterprise" Java (or dumbshits who do) then you'll know all about ESBs and how they're, in theory, the holy grail of solving the problem of integrating disparate systems.

    You'll also know that in reality, ESBs are slow, flaky, unreliable pieces of shit that fall over all the damn time for no good reason, yet no-one ever blames the ESB or suggests replacing it because it's the "backbone" of the system. Instead, your software that was interfacing with the ESB and expecting it to work (ha!) gets blamed.

    I'm not bitter at all.



  • @Ben L. said:

    WHAT THE FUCK DOES SOA STAND FOR?
     

    Sexueel Overdraagbare Aandoening.

    It's VD.



  • @The_Assimilator said:

    You'll also know that in reality, ESBs are slow, flaky, unreliable pieces of shit that fall over all the damn time for no good reason, yet no-one ever blames the ESB or suggests replacing it because it's the "backbone" of the system.
     

    It took me 5 seconds of reading the first paragraphs of the wikipagia to draw that conclusion.



  •  @skotl said:

    @blakeyrat said:
    @morbiuswilters said:
    @Ben L. said:
    WHAT THE FUCK DOES SOA STAND FOR?

    I figured ESB, and especially SOA, were pretty well-known acronyms.

    Among people who work with Oracle and Java bullshit maybe. I've never heard ESB in my career.

    I hate to agree with Ben L, but if you're willing to spent hundreds of words communicating with people maybe actually ensure they know what the fuck you're talking about at some point. Snoofle's usually pretty good about this, not sure what went wrong here.

    I come across ESB relativley often but then one of our dev teams specifically writes integrations for third parties, some of whom (a tiny minority) use an ESB

    If you've heard of / come across WebSphere MQ, RabbitMQ or even Biztalk, then these are ESBs

     

    Having said all of that, it was "The Next Big Thing" in the mid noughties but rightly died a death for the reasons mentioned by snoofle and Ronald - that it becomes unmanageable and ultra-expensive trying to connect everything to everything

    Ehr, ESB is a really fuzzy / misused term, just like SOA or cloud-computing is but your example would only fit the most narrow definition. In most cases, WebSphere MQ is just the message broker middleware as ESB software is expected to understand multiple message formats, take for example [url]http://en.wikipedia.org/wiki/IBM_WebSphere_ESB[/url] (discontinued) or [url]http://en.wikipedia.org/wiki/IBM_WebSphere_Message_Broker[/url] (examples abound, especially from IBM - they're in the Enterprisey Software Business afterall).



  • @The_Assimilator said:

    If you've ever worked with "enterprise" Java (or dumbshits who do) then you'll know all about ESBs and how they're, in theory, the holy grail of solving the problem of integrating disparate systems.

    You'll also know that in reality, ESBs are slow, flaky, unreliable pieces of shit that fall over all the damn time for no good reason.

    As I understand it, Java, and .NET and other such platforms already provide myriad methods for inter-process communication, which are general enough to be of use for many purposes. So, the job of a developer is generally to take those platforms, tools, etc, and create services that businesses need.



    So, an ESB just another example of developers talking the platform, tools, etc, and creating ANOTHER platform on top, which is general enough to be of use for many purposes, but which still needs to be configured to actually do anything. So, all an ESB does is put off the completion of any development task until next month.



    Why do developers always try and solve the general problem of "solving the general problem" without it actually occurring to them that at some stage SOMEONE is going to have to implement the business logic at some level, and that the person who knows what all the business rules are ISN'T going to be the one that does it (because he's usually paying the developer to do it).



  • @eViLegion said:

    Why do developers always try and solve the general problem of "solving the general problem" without it actually occurring to them that at some stage SOMEONE is going to have to implement the business logic at some level, and that the person who knows what all the business rules are ISN'T going to be the one that does it (because he's usually paying the developer to do it).

    ^^^ this! ^^^

    Exactly that. We get asked to integrate to some 3rd party CRM app and when we ask for the requirements we get some mealy-mouthed generalised reqs and then the killer; "...and it needs to be open and extensible so that we can connect it to any other app or add any other workflow, anytime, in the future"

    NO! Give us the requirements for what you need to integrate now! There is no such thing as an "anything to anything" integration, bus or workflow. That's the dumb-assed, fantasy-world thinking that gave us ESBs and SOA in the first place!



  • @blakeyrat said:

    I hate to agree with Ben L, but if you're willing to spent hundreds of words communicating with people maybe actually ensure they know what the fuck you're talking about at some point. Snoofle's usually pretty good about this, not sure what went wrong here.
    Yes, it's Enterprise Service Bus. I've been forced to work with these things for so long that sometimes I forget that the rest of the world has the good sense not to use them.I had worked for nearly 18 straight hours to diagnose all the levels of the problem and make the report. By the time I was done, I was kind of zonked out (it was after midnight when I made the post).

    It's just that these geniuses took idiocy to such an extreme level that I just had to share...





  • @eViLegion said:

    @The_Assimilator said:

    If you've ever worked with "enterprise" Java (or dumbshits who do) then you'll know all about ESBs and how they're, in theory, the holy grail of solving the problem of integrating disparate systems.

    You'll also know that in reality, ESBs are slow, flaky, unreliable pieces of shit that fall over all the damn time for no good reason.

    As I understand it, Java, and .NET and other such platforms already provide myriad methods for inter-process communication, which are general enough to be of use for many purposes. So, the job of a developer is generally to take those platforms, tools, etc, and create services that businesses need.



    So, an ESB just another example of developers talking the platform, tools, etc, and creating ANOTHER platform on top, which is general enough to be of use for many purposes, but which still needs to be configured to actually do anything. So, all an ESB does is put off the completion of any development task until next month.



    Why do developers always try and solve the general problem of "solving the general problem" without it actually occurring to them that at some stage SOMEONE is going to have to implement the business logic at some level, and that the person who knows what all the business rules are ISN'T going to be the one that does it (because he's usually paying the developer to do it).

    IMO ESBs, much like The Cloud™, are primarily a management/marketing-driven solution to a problem that doesn't exist. If you're a vendor, and you manage to sell an ESB to one of your clients, BAM you've got them as a client for life, because over time the ESB will grow to encompass the whole system, and no outside vendor will ever be able to comprehend the horror enough to take it over.

    That's how you tell the honest software dev houses from the dishonest ones. The honest ones will try to sell you a solution, the dishonest ones will try to sell you an ESB. And because stupid people (managers) are invariably put in charge of making procurement decisions, the guys peddling the ESB end up winning the contract. Then they make money while the honest software houses go out of business because of companies complaining about "poor quality".

    I have yet to see a "problem" that was "solved" by an ESB that didn't create a dozen different problems. I have also yet to see a problem that was "solved" by an ESB when it couldn't have been solved by SOA with much less pain.


  • Considered Harmful

    @The_Assimilator said:

    IMO ESBs, much like The Cloud™, are primarily a management/marketing-driven solution to a problem that doesn't exist. If you're a vendor, and you manage to sell an ESB to one of your clients, BAM you've got them as a client for life, because over time the ESB will grow to encompass the whole system, and no outside vendor will ever be able to comprehend the horror enough to take it over.

    That's how you tell the honest software dev houses from the dishonest ones. The honest ones will try to sell you a solution, the dishonest ones will try to sell you an ESB. And because stupid people (managers) are invariably put in charge of making procurement decisions, the guys peddling the ESB end up winning the contract. Then they make money while the honest software houses go out of business because of companies complaining about "poor quality".

    It must be very appealing to the naïve and the gullible. Why would you buy one solution when you can buy all the solutions? You just someone to build the solution into the Solution and then expensive consultants to maintain it for the rest of its lifetime (which is indefinite, because it's so integral to everything that you can't remove it).



  • This reminds me that I bookmarked an interesting article by Bobby Woolf (one of the two authors who coined (most of) the terms in the field of Enterprise Integration), which he wrote while working for IBM:

    [url=http://www.ibm.com/developerworks/webservices/library/ws-soa-esbarch/]ESB-oriented architecture: The wrong approach to adopting SOA[/url]

     It's title and content seems to have gotten the managers so riled up that they felt the need to add an Editor's note and sidebar to explain that you shouldn't jump into this without thinking, and yes, you still need to give them the money. And there's even more sales goodness after the break.



  • @Ben L. said:

  • E ast S ide B oys... a street gang in eastside Kansas City. Rival to the Brookside W est S ide B itchy B oys.... ESB territory is from east 51st St. to east 59th St. 3 main Gang leaders live in the middle of he turf around Brookside Park
  • I have a horribly shitty [redundant. -ed.] Pet Shop Boys song going through my head right now. Thanks a lot, jerk.



  • @Ronald said:

    You're not a team player.
    Given his team, that's a good thing.



  •  OK, the ESBESB is a WTF...but a well designed ESB is indeed quite powerful. Unlike many (most) types of IPC, the key element is that the sender does not know (or care) who or what is on the other end, what protocols the other end uses, or anything beyond their own local contract with the ESB. When the number of interconnected systems rises (think thousands or more in a large organization like a government) then this level of isolation and independence become a lifesaver...



  • @blakeyrat said:

    @morbiuswilters said:
    @Ben L. said:
    WHAT THE FUCK DOES SOA STAND FOR?

    I figured ESB, and especially SOA, were pretty well-known acronyms.

    Among people who work with Oracle and Java bullshit maybe. I've never heard ESB in my career.

    Haha, you don't know what an ESB is.



  • @TheCPUWizard said:

    Unlike many (most) types of IPC, the key element is that the sender does not know (or care) who or what is on the other end
     

    So, you can just query the floorplan and the finantial statements from the HR system?



  • @TheCPUWizard said:

     OK, the ESBESB is a WTF...but a well designed ESB is indeed quite powerful. Unlike many (most) types of IPC, the key element is that the sender does not know (or care) who or what is on the other end, what protocols the other end uses, or anything beyond their own local contract with the ESB. When the number of interconnected systems rises (think thousands or more in a large organization like a government) then this level of isolation and independence become a lifesaver...


    Some people, when confronted with a protocol, think "I know, I'll use an ESB." Now they have three protocols.

    (Somewhat related, just when you thought Minecraft couldn't get any worse, [url=http://wiki.vg/Protocol#Chat_Message_.280x03.29]it now encodes chat messages in JSON[/url])



  • @immibis said:

    (Somewhat related, just when you thought Minecraft couldn't get any worse, it now encodes chat messages in JSON)

    That doesn't seem so bad. Text-based protocols are a lot easier to work with than binary ones, and it's not like making chat messages a bit bigger is going to have any noticeable impact on performance. It really seems like a step in the right direction.



  • @morbiuswilters said:

    @immibis said:
    (Somewhat related, just when you thought Minecraft couldn't get any worse, it now encodes chat messages in JSON)

    That doesn't seem so bad. Text-based protocols are a lot easier to work with than binary ones, and it's not like making chat messages a bit bigger is going to have any noticeable impact on performance. It really seems like a step in the right direction.

    Yet some geniuses are proposing that HTTP/2.0 be a binary protocol. THIS IS WHY WE CAN'T HAVE NICE THINGS.



  • @The_Assimilator said:

    Yet some geniuses are proposing that HTTP/2.0 be a binary protocol. THIS IS WHY WE CAN'T HAVE NICE THINGS.

    First of all, don't believe anything you read on SLASHDOT of all places. Idiot.

    Secondly, they also said HTTP 2.0 won't be a required update in any way, shape, or form. So if you don't want t binary protocol, don't use one.

    Thirdly, what's wrong with it being a binary protocol in the first place? Assuming it even is. Which it isn't. Because Slashdot said it is. And they're wrong all the fucking time.

    Fourthly, this leg cramp woke me up at fucking 4:37 AM and I hate life and am in pain.


  • ♿ (Parody)

    @blakeyrat said:

    @The_Assimilator said:
    Yet some geniuses are proposing that HTTP/2.0 be a binary protocol. THIS IS WHY WE CAN'T HAVE NICE THINGS.

    First of all, don't believe anything you read on SLASHDOT of all places. Idiot.

    But we should believe things we read on TDWTF? Idiot.



  • @blakeyrat said:

    Thirdly, what's wrong with it being a binary protocol in the first place? Assuming it even is. Which it isn't. Because Slashdot said it is. And they're wrong all the fucking time.
    General rule of thumb:

    If Slashdot was broadcast news, this article would be a "man bites dog" story.

    Except no one was bitten.

    And it's a cat.



  • @El_Heffe said:

    General rule of thumb:

    If Slashdot was broadcast news, this article would be a "man bites dog" story.

    Except no one was bitten.

    And it's a cat.

    And Draconian DRM Revealed in Windows 7.


  • Discourse touched me in a no-no place

    @El_Heffe said:

    General rule of thumb:

    If Slashdot was broadcast news, this article would be a "man bites dog" story.

    Except no one was bitten.

    And it's a cat.

    And the same story would be repeated next week because one of the reporters was too slow to realize that the same thing had been written before. And the editor in charge (hah!) wouldn't have the memory to remember it.


  • Considered Harmful

    @blakeyrat said:

    Assuming it even is. Which it isn't. Because Slashdot said it is. And they're wrong all the fucking time.

    Slashdot reliability (or lack thereof) not withstanding, the spec they linked does appear to be a binary protocol.

    [quote user="Spec"]
    All frames begin with an 8-octet header followed by a payload of
       between 0 and 65,535 octets.
    
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         Length (16)           |   Type (8)    |   Flags (8)   |
    +-+-------------+---------------+-------------------------------+
    |R|                 Stream Identifier (31)                      |
    +-+-------------------------------------------------------------+
    |                   Frame Payload (0...)                      ...
    +---------------------------------------------------------------+
    
                               Frame Header
    

    The fields of the frame header are defined as:

    Length: The length of the frame payload expressed as an unsigned 16-
    bit integer. The 8 octets of the frame header are not included in
    this value.

    Type: The 8-bit type of the frame. The frame type determines how
    the remainder of the frame header and payload are interpreted.
    Implementations MUST ignore unsupported and unrecognized frame
    types.

    Flags: An 8-bit field reserved for frame-type specific boolean
    flags.

      Flags are assigned semantics specific to the indicated frame type.
      Flags that have no defined semantics for a particular frame type
      MUST be ignored, and MUST be left unset (0) when sending.
    
    [/quote]


  • @dkf said:

    And the same story would be repeated next week because one of the reporters was too slow to realize that the same thing had been written before. And the editor in charge (hah!) wouldn't have the memory to remember it.
     

    Back during their heyday, it was common for support people at my company to use '/.' as an abbreviation for 'repeat issue I'm closing without comment'. Another company I worked for years later used it as an abbreviation for 'customer using too much upstream, yell at him'.



  • @joe.edwards said:

    Slashdot reliability (or lack thereof) not withstanding, the spec they linked does appear to be a binary protocol.

    Slashdot could report "Water Wet!" and I wouldn't believe it.



  • @blakeyrat said:

    @The_Assimilator said:
    Yet some geniuses are proposing that HTTP/2.0 be a binary protocol. THIS IS WHY WE CAN'T HAVE NICE THINGS.

    First of all, don't believe anything you read on SLASHDOT of all places. Idiot.

    Secondly, they also said HTTP 2.0 won't be a required update in any way, shape, or form. So if you don't want t binary protocol, don't use one.

    Thirdly, what's wrong with it being a binary protocol in the first place? Assuming it even is. Which it isn't. Because Slashdot said it is. And they're wrong all the fucking time.

    Fourthly, this leg cramp woke me up at fucking 4:37 AM and I hate life and am in pain.

    blakey, I appreciate that your troll post detector doesn't work so well at 4:37 AM, so I'm going to let this one slide. Just this once, you understand.



  • @blakeyrat said:

    @joe.edwards said:
    Slashdot reliability (or lack thereof) not withstanding, the spec they linked does appear to be a binary protocol.

    Slashdot could report "Water Wet!" and I wouldn't believe it.

    Redmond Announces Microsoft Water



  • @dkf said:

    @El_Heffe said:
    General rule of thumb:

    If Slashdot was broadcast news, this article would be a "man bites dog" story.

    Except no one was bitten.

    And it's a cat.

    And the same story would be repeated next week the next day because one of the reporters was too slow to realize that the same thing had been written before. And the editor in charge (hah!) wouldn't have the memory to remember it.

     

     



  • @joe.edwards said:

    Slashdot reliability (or lack thereof) not withstanding, the spec they linked does appear to be a binary protocol.
    Some things posted on Slashdot are just wrong or stupid, like the "OMG KILLER DRM IN WINDOZE 7!!!" that Blakeyrat mentioned already.  But many times there's a link to an article that's legitimate and actually interesting.  The key is to ignore the stupid and poorly written Slashdot summary and just follow the link to the real story.  And ignore all the comments, most of which make our Spectate Swamp thread look sane by comparison.


  • Considered Harmful

    @El_Heffe said:

    @joe.edwards said:

    Slashdot reliability (or lack thereof) not withstanding, the spec they linked does appear to be a binary protocol.
    Some things posted on Slashdot are just wrong or stupid, like the "OMG KILLER DRM IN WINDOZE 7!!!" that Blakeyrat mentioned already.  But many times there's a link to an article that's legitimate and actually interesting.  The key is to ignore the stupid and poorly written Slashdot summary and just follow the link to the real story.  And ignore all the comments, most of which make our Spectate Swamp thread look sane by comparison.

    I agree, which is why I was confused by the speculation in this thread, when all anyone had to do was click on the source link and read— ohhh.



  • @The_Assimilator said:

    Yet some geniuses are proposing that HTTP/2.0 be a binary protocol. THIS IS WHY WE CAN'T HAVE NICE THINGS.

    Fucking up the web: Not just for the W3C anymore.™

    I read the first dozen comments or so, and let me say: Slashdot is just as retarded as ever. Look at all of the people claiming this will reduce parser bugs and make HTTP faster. Ugh.

    Next up: let's replace HTML with ASN.1!



  • @blakeyrat said:

    Secondly, they also said HTTP 2.0 won't be a required update in any way, shape, or form.

    Either HTTP 2.0 will have some features that 1.1 won't have (which means you have to upgrade to use them) or it's just pointless.

    @blakeyrat said:

    Thirdly, what's wrong with it being a binary protocol in the first place?

    A lot? Binary protocols are fucking hell to extend, debug and implement.



  • @morbiuswilters said:

    A lot? Binary protocols are fucking hell to extend, debug and implement.

    Some dude at Microsoft's problem, not mine.

    I know you work for a development platform stuck in 1976, but here at the "bleeding edge" we have a guy to do shit like that so we don't have to.


Log in to reply