• sam (unregistered)

    I'm interested to know wtf is "ghettoPartID"?

  • (cs)

    Well, frist of all, since they were dealing with images, why couldn't the server put it on a wooden table and take a snapshot of it to email?

    Added: oh, I don't mean frist... I mean fecund.

  • (cs)

    And I know this isn't the point, but why did the email keep failing? I assume it was on the same network.

  • (cs)

    Nothing works in the ghetto.

  • (cs) in reply to FredSaw
    FredSaw:
    Well, frist of all, since they were dealing with images, why couldn't the server put it on a wooden table and take a snapshot of it to email?

    No, the server should put it on a wooden table, take a polaroid, then scan in the polaroid and fax it to the transcoder server...

  • crash & burn (unregistered) in reply to ssanders82
    ssanders82:
    FredSaw:
    Well, frist of all, since they were dealing with images, why couldn't the server put it on a wooden table and take a snapshot of it to email?

    No, the server should put it on a wooden table, take a polaroid, then scan in the polaroid and fax it to the transcoder server...

    No, No, Server should do it at least 3 times before sending, so it can compare and decide which is best quality outcome...

  • Mad Genius (unregistered)

    It's propably just a faulty wire on the company's WLAN.

  • Bill Brasky (unregistered)

    I'm not sure that sending XML via SMTP is a WTF. You're delivering a message and that's what SMTP does. Many SOAP engines support sending SOAP messages over SMTP.

    Probably the real WTF is ghettoPartId.

  • (cs)

    This process would be much more efficient if the Transcoding Server received the message by carrier pigeon instead. When will people learn?

  • (cs) in reply to sam

    No no no!

    The server needs to print out the email before sending, take a picture, auto stuff, stamp, address and snail-mail it, and then drop the e-mail. Several days (or in rare cases, years) later, the remote server can auto-open and parse the paper mail and proceed. Of course, digital images of all paper correspondance will be stored on microfiche for 99 years.

    Of course, we can take it to the next level, and etch the image directly into the wooden table and ship IT!

  • (cs)

    As someone else points out, a web service is not limited to using HTTP as its transport, despite having "web" in the name. If you've already got an MTA on both servers, why go to the bother of having to setup a web application just to be able to use HTTP for your web service. Definitely not a WTF.

  • Dan Gardner (unregistered)

    What is wrong with using SMTP for passing messages between servers? It is extremely robust - if the Transcoding Server was not available for some reason, the message should have been queued and delivered when the server became available again. It can support authentication (TLS) and handles transport failures gracefully, all without any additional application code. I see no point in re-inventing the wheel.

    Unless they were using Microsoft sExchange as their MTA (which would be a WTF) I can't see the problem here.

  • bling (unregistered) in reply to Dan Gardner
    Dan Gardner:
    What is wrong with using SMTP for passing messages between servers? It is extremely robust

    If by "extremely robust" you mean that the application has no way of knowing whether the message was actually delivered, yes. Especially assuming along the path of delivery there is no spam filtering or blackholing going on.

  • Locutus (unregistered) in reply to T $
    T $:
    This process would be much more efficient if the Transcoding Server received the message by carrier pigeon instead. When will people learn?

    EXACTLY! How hard would it be to implement RFC 1149 ??

  • dkf (unregistered) in reply to Dan Gardner
    Dan Gardner:
    What is wrong with using SMTP for passing messages between servers? It is extremely robust
    The phrase you are looking for here is "enterprisey".
  • Waigl (unregistered)

    Actually, this sort of thing (communication between two servers via email) is pretty common, especially in the world of automated domain registrations.

    Fortunately, it's getting rarer these days, though.

  • Dan Gardner (unregistered) in reply to bling
    bling:
    If by "extremely robust" you mean that the application has no way of knowing whether the message was actually delivered, yes.

    Of course the application can know whether the message was delivered. Given a properly configured MTA, the absence of a bounce will indicate that the message was delivered. It may not be immediate but that applies to any system involving submitting a message to a queue.

  • perdidopunk (unregistered)

    Nobody has considered using an automatic typesetter to set the message and print it in the personals section of the daily paper.

    CAPTCHA: riaa

    i hate them!

  • dkf (unregistered) in reply to Bill Brasky
    Bill Brasky:
    I'm not sure that sending XML via SMTP is a WTF. You're delivering a message and that's what SMTP does.
    The failure might be down to something as simple as the fact that there's a secretary on vacation so there's nobody about to retype the request from Outlook Express into Excel (where a load of macros are the "Transcoding Server"...)
  • (cs) in reply to Locutus
    Locutus:
    EXACTLY! How hard would it be to implement RFC 1149 ??
    I have to admire Joe's perceptive, insightful comment on the proposal.
  • totiredtowork (unregistered)

    Reminds me of one time when I requested a customer to email me an excel document. He then:

    1. Printed the excel sheet.
    2. Scanned the printed dokument.
    3. Emailed me the jpeg.
  • totiredtowork (unregistered)

    Reminds me of one time when I requested a customer to email me an excel document. He then:

    1. Printed the excel sheet.
    2. Scanned the printed document.
    3. Emailed me the jpeg.
  • nerd (unregistered)

    concur. there's nothing wrong with using SMTP for messaging. Not really a WTF if you ask me...

  • (cs) in reply to bling
    bling:
    Dan Gardner:
    What is wrong with using SMTP for passing messages between servers? It is extremely robust

    If by "extremely robust" you mean that the application has no way of knowing whether the message was actually delivered, yes. Especially assuming along the path of delivery there is no spam filtering or blackholing going on.

    Well, given that the setup looks like an internal processing system, then only a mis-configured MTA is going to send the messages via the Internet where it may be filtered. Even if it was going over the Internet, it's got as much chance of working as over HTTP, given the firewalling that's likely to be in place between the servers. As for reliability, you've clearly not worked on any systems using SMTP - there are these things called "bounces" that acknowledge delivery failure at the receiving MTA or any intermediate relays. There are also common ways to acknowledge receipt of the message, and if the receiving MTA is down, the sender will keep trying to deliver for a fixed period or number of attempts if configured to do so.

    As an aside, "fire and forget" with no guarantee of success is a common delivery method in everything from network protocols (UDP for example) to remote procedure call setups (one way invocation in CORBA for example).

  • 1337 (unregistered)

    i hear stamps are cheaper then bars of soap

  • (cs)

    I used to work for a company that did voicemail products (and you've seen a lot of their work on the sidebar forum). Sending messages like this via SMTP was pretty common, both among internal apps and 3rd party vendors we had to negotiate with. Not sure it's really a WTF.

    Since the messages were stored as emails on an IMAP server, SMTP is a natural way to put them on there. I think that made SMTP a more desirable communications method for other processes as well. For example, once a message was sent, the main copy gets SMTPed to the mail store, and a copy just gets sent to the notification server. Why send the message in two formats?

    Also keep in mind that SMTP does not really mean email. It's just a protocol for sending messages. Most of the overhead associated with sending an email wouldn't apply in this case, because the transcoding server was most likely just listening on port 25 and doing its own thing.

    There was a transcoding server similar to this in development when I left. I'd be willing to be that it transfered messages via SMTP as well.

  • (cs) in reply to Waigl
    Waigl:
    Actually, this sort of thing (communication between two servers via email) is pretty common, especially in the world of automated domain registrations.

    Fortunately, it's getting rarer these days, though.

    I thought spam was becoming more common these days? :)

  • Badger (unregistered) in reply to rbowes

    Reminds me of that funky setup Network Solutions used back in the day to manage domain names.

    I agree with the sentiment though, SMTP is a solid messaging & queuing, cross-platform, cheap system. Decoupling a request for transcoding from the transcoding server is smart. I'd imagine the transcoding servers would be heavily loaded due to the type of processing they do. Otherwise you'd have to roll your own queue & messaging system.

  • John Doe (unregistered) in reply to FredSaw
    FredSaw:
    Locutus:
    EXACTLY! How hard would it be to implement RFC 1149 ??
    I have to admire Joe's perceptive, insightful comment on the proposal.
    Why? He obviously missed the date at the top of the proposal, so didn't grab its intention. It's been a tradition at the IETF to submit RFC's at April 1st, and this is one of my favourites :)

    To make it more robust, err, enterprisey, I'd suggest to use RFC 2549.

  • foo (unregistered)

    Some how I thought Java would be better when I left Perl behind... now I see that it wasn't Perl that was screwed up.

  • (cs)

    I think you all missed the best solution. The server should print an A3 sheet with instructions for the operator to perform in order to conform to RFC 4824. The instructions should use the operator's face and general body structure so that there is no confusion.

    Furthermore, a device that has several buttons with all the possible instructions must be created to ease the work of the receiving operator.

    Lastly, the operators should be equiped with a special outfit that has lots of blinking LEDs so that data can be transferred even during the night.

    I think I should see a doctor. A psychiatrist, preferably, but in my condition anyone would do.

  • (cs) in reply to foo
    foo:
    Some how I thought Java would be better when I left Perl behind... now I see that it wasn't Perl that was screwed up.

    The (alleged) WTF here is that SMTP is being used as a delivery method for processing requests, a sort of asynchronous remote procedure call. How you can interprete that as something you can beat Java with is beyond me. So just to counter your wild assertion, here's mine. Every large system written in Perl that I've encountered has been a mass of unstructured spaghetti, which is only understood (if at all) by the original author. Therefore Perl sucks for anything more than a one-shot throwaway hack.

  • (cs)

    No, just No.

    First of all,

    The server should have printed the image on a wooden table, where it will be snail-mailed. Once recieved it will be stored in a filing cabinet and a morse code message will be sent upon it's filing back to the IT department (to prevent nazi's from intercepting it of course)!

  • Nobody (unregistered)

    From the SOAP Wikipedia entry:

    Both SMTP and HTTP are valid application layer protocols used as Transport for SOAP, but HTTP has gained wider acceptance as it works well with today's Internet infrastructure; specifically, SOAP works well with network firewalls.

    If Wikipedia says it, it has to be true!

    OTH, if ghettoPartId isn't a WTF, it's got to at least be a good joke!

  • (cs)

    This doesn't really seem that bad to me. As someone else mentioned, SOAP can do it, and it does constitute a sort of load-distribution system for the case where requests don't have to be acted upon immediately; they can just pile up in the queue.

  • toby (unregistered)

    OK, at least they built the XML correctly! Here's the C# code I "inherited" to create a web request for an internal app. At least they actually converted the quotes and angle brackets...

    public string BuildRegistration(Config config, IEmployee Employee, string PlanXml)
{
    StringBuilder content = new StringBuilder();

    content.Append("<?xml version=\"1.0\" encoding=\"utf-8\"?>\n");

    content.Append("<!DOCTYPE InitechRegistration PUBLIC '/dtd/InitechRegistration.dtd'  'http://www.initech.com/dtd/InitechRegistration.dtd'>\n");

    content.Append("<InitechRegistration Environment=\"").Append(config.Environment.ToUpper()).Append("\" Status=\"RUN\" Client_ID=\"").Append(config.SponsorCode).Append("\" Subcode=\"").Append(Employee.BenefitCode).Append("\" EnrollmentYear=\"").Append(config.PlanYear).Append("\" SessionURL=\"http://www.initech.com\">\n");

    content.Append("  <Employee Person_ID=\"").Append(Employee.EmployeeID).Append("\" CurrentOptionLevel=\"").Append(Employee.BenefitGroupCode).Append("\" ZipCode=\"").Append(Employee.ZipCode).Append("\" />\n");

    content.Append("  <PlanEligibility CostStructure=\"NON-UNITIZED\">  \n");

    content.Append(PlanXml).Append("\n");

    content.Append("  </PlanEligibility>\n");

    content.Append("</InitechRegistration>\n");

    content = content.Replace("<", "<");
    
    content = content.Replace(">", ">");
    
    content = content.Replace("\"", """);

    return content.ToString();
}
  • (cs) in reply to java.lang.Chris;
    java.lang.Chris;:
    foo:
    Some how I thought Java would be better when I left Perl behind... now I see that it wasn't Perl that was screwed up.

    The (alleged) WTF here is that SMTP is being used as a delivery method for processing requests, a sort of asynchronous remote procedure call. How you can interprete that as something you can beat Java with is beyond me. So just to counter your wild assertion, here's mine. Every large system written in Perl that I've encountered has been a mass of unstructured spaghetti, which is only understood (if at all) by the original author. Therefore Perl sucks for anything more than a one-shot throwaway hack.

    Ooh look -- language flames wars, just when you least expect them.

    I'm not that keen on Java, and I'm not that keen on Perl. My attitude to this is that a "new" language has to offer significant benefits to it's predecessor(s).

    Perl is much, much better than shell scripting. (It's even multi-platform: woo-hoo!)

    Java is not, in any obvious way that I can discern, superior to C++. In fact, I would characterise it as a step back.

    There are plenty of half-way decent Perl systems out there (including a shed-load of Web systems). I have yet to see a Java system that isn't a car-crash waiting to happen.

    But thenn again, I don't look very hard.

    Now, if you don't mind, I'm going to go back to figuring out how to make JNI work with a disparate collection of Windows DLLs. Perl and SWiG would be so much better at the glue function here.

  • rast (unregistered) in reply to totiredtowork
    totiredtowork:
    Reminds me of one time when I requested a customer to email me an excel document. He then: 1) Printed the excel sheet. 2) Scanned the printed document. 3) Emailed me the jpeg.
    totiredtowork:
    Reminds me of one time when I requested a customer to email me an excel document. He then: 1) Printed the excel sheet. 2) Scanned the printed document. 3) Emailed me the jpeg.

    The real WTF is that he did it twice!

  • (cs) in reply to crash & burn
    crash & burn:
    ssanders82:
    FredSaw:
    Well, frist of all, since they were dealing with images, why couldn't the server put it on a wooden table and take a snapshot of it to email?

    No, the server should put it on a wooden table, take a polaroid, then scan in the polaroid and fax it to the transcoder server...

    No, No, Server should do it at least 3 times before sending, so it can compare and decide which is best quality outcome...

    how about having the Client take the pictures, so there are more options. then the client can email them to the server. The server can snail-mail proofs to kinkos to have them cropped and printed on photo paper. kinkos mails them back and then the server scans in it's favorites... and then prints them out on a dot-matrix printer to reduce the resolution. then the server can just give them to the media server, which will scan them in and -boom baby!-.

  • Anonymous coward (unregistered) in reply to toby
    toby:
    OK, at least they built the XML correctly! Here's the C# code I "inherited" to create a web request for an internal app. At least they actually converted the quotes and angle brackets... 
    public string BuildRegistration(Config config, IEmployee Employee, string PlanXml)
{
    StringBuilder content = new StringBuilder();

    content.Append("<?xml version=\"1.0\" encoding=\"utf-8\"?>\n");

    content.Append("<!DOCTYPE InitechRegistration PUBLIC '/dtd/InitechRegistration.dtd'  'http://www.initech.com/dtd/InitechRegistration.dtd'>\n");

    content.Append("<InitechRegistration Environment=\"").Append(config.Environment.ToUpper()).Append("\" Status=\"RUN\" Client_ID=\"").Append(config.SponsorCode).Append("\" Subcode=\"").Append(Employee.BenefitCode).Append("\" EnrollmentYear=\"").Append(config.PlanYear).Append("\" SessionURL=\"http://www.initech.com\">\n");

    content.Append("  <Employee Person_ID=\"").Append(Employee.EmployeeID).Append("\" CurrentOptionLevel=\"").Append(Employee.BenefitGroupCode).Append("\" ZipCode=\"").Append(Employee.ZipCode).Append("\" />\n");

    content.Append("  <PlanEligibility CostStructure=\"NON-UNITIZED\">  \n");

    content.Append(PlanXml).Append("\n");

    content.Append("  </PlanEligibility>\n");

    content.Append("</InitechRegistration>\n");

    content = content.Replace("<", "<");
    
    content = content.Replace(">", ">");
    
    content = content.Replace("\"", """);

    return content.ToString();
}

    Wow... Oh well, at least they used a StringBuilder instead of just concatenating a string...

  • (cs) in reply to java.lang.Chris;
    java.lang.Chris;:
    bling:
    Dan Gardner:
    What is wrong with using SMTP for passing messages between servers? It is extremely robust

    If by "extremely robust" you mean that the application has no way of knowing whether the message was actually delivered, yes. Especially assuming along the path of delivery there is no spam filtering or blackholing going on.

    Well, given that the setup looks like an internal processing system, then only a mis-configured MTA is going to send the messages via the Internet where it may be filtered. Even if it was going over the Internet, it's got as much chance of working as over HTTP, given the firewalling that's likely to be in place between the servers. As for reliability, you've clearly not worked on any systems using SMTP - there are these things called "bounces" that acknowledge delivery failure at the receiving MTA or any intermediate relays. There are also common ways to acknowledge receipt of the message, and if the receiving MTA is down, the sender will keep trying to deliver for a fixed period or number of attempts if configured to do so.

    As an aside, "fire and forget" with no guarantee of success is a common delivery method in everything from network protocols (UDP for example) to remote procedure call setups (one way invocation in CORBA for example).

    strangely, you contradicted yourself with the response that I was going to post. Fire and Forget is a massive fault with SMTP over HTTP. a process sending over HTTP does have a greater chance then sent of SMTP, because the same process will not catch the SMTP bounce... and because with HTTP you can return errors to the originating process. So no, SMTP is not as reliable as HTTP, not even close.

  • sf (unregistered) in reply to real_aardvark
    real_aardvark:
    java.lang.Chris;:
    foo:
    Some how I thought Java would be better when I left Perl behind... now I see that it wasn't Perl that was screwed up.

    The (alleged) WTF here is that SMTP is being used as a delivery method for processing requests, a sort of asynchronous remote procedure call. How you can interprete that as something you can beat Java with is beyond me. So just to counter your wild assertion, here's mine. Every large system written in Perl that I've encountered has been a mass of unstructured spaghetti, which is only understood (if at all) by the original author. Therefore Perl sucks for anything more than a one-shot throwaway hack.

    Ooh look -- language flames wars, just when you least expect them.
    And then you proceed to regal us with your unsubstantiated opinions. Please take these old and tired arguments to another forum. To everyone else: PLEASE DON'T FEED THE TROLLS!
  • Jasper Mantooth (unregistered) in reply to akatherder
    akatherder:
    Nothing works in the ghetto.

    this->self comment wins...

  • Tukaram (unregistered)

    Hello,

    for those who cannot see the WTF:

    Email works. But think about the main task: Sending multimedia stuff (like Movies, MP3). And sending binaries via email means that the system needs three times more space (uuencoding).

    In case of a movie (600MB) the system has to allocate 1.8 GB of memory. For one email.

    And: The common email systems have a limitation for email size. And that limitation is much smaller than 1.8GB ;-)

    Regards

  • (cs) in reply to Tukaram
    Tukaram:
    Hello,

    for those who cannot see the WTF:

    Email works. But think about the main task: Sending multimedia stuff (like Movies, MP3). And sending binaries via email means that the system needs three times more space (uuencoding).

    In case of a movie (600MB) the system has to allocate 1.8 GB of memory. For one email.

    And: The common email systems have a limitation for email size. And that limitation is much smaller than 1.8GB ;-)

    Regards

    I thought that pretty much all email systems had switched over to base64 at this point. Is that wrong? Even so, uuencode and base64 are both about 1.3x the size, not 3x, and the implementations I've seen en/decode on the fly, allocating in 4-32k chunks.

  • Buckaroo Bonzai (unregistered) in reply to crash & burn
    crash & burn:
    ssanders82:
    FredSaw:
    Well, frist of all, since they were dealing with images, why couldn't the server put it on a wooden table and take a snapshot of it to email?

    No, the server should put it on a wooden table, take a polaroid, then scan in the polaroid and fax it to the transcoder server...

    No, No, Server should do it at least 3 times before sending, so it can compare and decide which is best quality outcome...

    Really? I didn't know you could do that?

  • sf (unregistered) in reply to Tukaram
    Tukaram:
    Hello,

    for those who cannot see the WTF:

    Email works. But think about the main task: Sending multimedia stuff (like Movies, MP3). And sending binaries via email means that the system needs three times more space (uuencoding).

    In case of a movie (600MB) the system has to allocate 1.8 GB of memory. For one email.

    And: The common email systems have a limitation for email size. And that limitation is much smaller than 1.8GB ;-)

    Regards

    True, except in this case, based on the steps taken above, it appears that only the request is sent via SMTP. The actual file upload happens later.

    I have to agree with others that this isn't realy so bad. I wouldn't try to do this kind of thing though. They're just using SMTP as a sort of poor man's message queue.

  • James (unregistered) in reply to Tukaram
    Tukaram:
    In case of a movie (600MB) the system has to allocate 1.8 GB of memory. For one email.

    And: The common email systems have a limitation for email size. And that limitation is much smaller than 1.8GB ;-)

    RTFC -- Read The Fine Code, my friend. The message's dynamic fields are two integers and two strings. The movie is probably on a web server at a location pointed to by the "location" parameter. The message should only be one or two KB, if that, no binary-stream data included.

    I'm still trying to figure out what's wrong here -- SMTP strikes me as a bit odd, but what's the "right" way to do asynchronous messaging between two automated systems across unknown network layers? My mind probably wouldn't jump right to SMTP, but on reflection it's probably one of the more robust transports that I can come up with. Sure, they could send it as an HTTP request, but is that really "better" in any objective way?

    On the other hand, I'm baffled at why this system broke (given our very limited information). Maybe the "Real WTF (TM)(R)(C)(SM)" is that they have the Transcoding server checking a 3rd-party email service, with a small quota, and some of the messages are getting bounced from a full mailbox? Or something? I mean, that would be a WTF, but the basic choice of SMTP doesn't seem like one to me.

    P.S.: The whole "photo on a wooden table" thing stays funny for maybe 5-10 comments, but it's really getting old. We got the joke; please stop flogging it.

  • maht (unregistered)

    I bet some of you have never even had an email server that executed the body of your emails as shell script and mailed you back the results.

    Or got excited the first day you printed to fax.

    I wonder what will be considered your things that are really exciting now but will sound ridiculous or banal in 10 years.

  • (cs) in reply to John Doe
    John Doe:
    FredSaw:
    Locutus:
    EXACTLY! How hard would it be to implement RFC 1149 ??
    I have to admire Joe's perceptive, insightful comment on the proposal.
    Why? He obviously missed the date at the top of the proposal, so didn't grab its intention. It's been a tradition at the IETF to submit RFC's at April 1st, and this is one of my favourites :)

    To make it more robust, err, enterprisey, I'd suggest to use RFC 2549.

    Well, I missed the date, too, but I know better than to imagine that a proposal like RFC 1149 was given seriously. So my praise for Joe was a tongue-in-cheek attempt to heap derision on him for thinking it was a genuine proposal.

Leave a comment on “Old Fashioned Web Services”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article