Stripmall Architecture

Hey guess what, iPhone 4.0b photo app crashes every single time I take a photo. Probably violating a clickwrap NDA by telling you this. Sent from John's still-working phone.

(Also this didn't post the first time because they changed the mail client to emit that two-decade bane of my existence, multipart/related, so I had to hack my posting script to understand that too. Fuck.)

Tags: , , ,

17 Responses:

  1. hatter says:

    It's a feature - the world you perceive does not exist, only that which apple prescribes.

    the hatter

  2. davachu says:

    Get a real camera.

    • jwz says:

      I have several real cameras. They're big.

      • davachu says:

        Canon S90: ISO3200, spot meter, full manual and RAW. And it's tiny. See if you've got someone in the club with one.

        Having said that, I still haven't quite got it right in gigs. But I've only played when I've been packing the real camera.

        • jwz says:

          See, then that would be another piece of junk I'd have to lug around and it would fail the first test of any camera: being the camera I have with me. I always have my phone with me. Conveniently, it has a camera in it. My pockets do not have another 11 cu. in. to spare.

          • davachu says:

            I always have both with me. Right front jeans pocket. iPhone left front.

            And it saves me lugging the stupid SLR.

            But until I actually take a compelling pic at a gig, it's all moot anyhow.

            Keep calm and carry on.

    • rodgerd says:

      I have a real camera, but I still end up using my camera phone more these days. It's the one I always have with me (although I bought my phone for a good-for-the-form camera, rather than a locked-down half-assed Unix implementation).

  3. injector says:

    I've seen it recommended that mail servers reject multipart/related, because it makes scanning for viruses much more difficult.

    • scullin says:

      As much as I find it annoying when mail programs resort to unnecessary MIME encapsulations -- I'm sorry, if you're anti-virus software can't handle established, documented encodings, it's a steaming pile of shit.

      • injector says:

        On the client it's simple: If you have all the pieces needed to be infected you assemble and scan. But on the server side, the server would have to be able to understand MIME, know to hold all the pieces in the queue until the last arrives (which could be any time in the future), and then either, again know MIME well enough to assemble all the parts and pass the file to the scanner, or inform the scanner to check all the pieces at the same time, and have the scanner know to assemble them rather than scan as individual files.

        • scullin says:

          Please go back and read the MIME RFCs and then try to tell me if anything you just said makes any sense.

          • injector says:


            The Multipart/Related media type is intended for compound objects
            consisting of several inter-related body parts. For a
            Multipart/Related object, proper display cannot be achieved by
            individually displaying the constituent body parts.

            So yes, everything I said makes perfect sense.

            Multipart/Related is most often used to get around the per-message size limitation of SMTP, the file is divided into multiple body parts, which are each sent in turn as individual e-mails. The client then reassembles by following the MIME headers. Servers are not designed to understand that one message relates to another. Server-based AV scanners are designed to scan messages in the queue before they are delivered to the user. If the server doesn't know to keep each part around until they all arrive, the scanner can't get the full picture.

            • scullin says:

              In short, no. The most common application of multipart/related is sending rich messages with embedded content. For example, an HTML message with images. There's nothing in RFC 2387 about splitting up messages, or size limitations of SMTP.

              In long, let me stretch for an example: Say you are a hacker-cum-beer seller trying to send an image and some comments from your phone from a concert. You might think that it would send your message in two simple chunks - your comments, with the image as an attachment. But if your overly ambitious phone thought that the image was actually part of some elaborate rich-text message, it might create a multipart/related message with an HTML chunk that references the image, with the image in another multipart/related chunk. It would then be up to the client to render the HTML part with the embedded image, and not treat them both as a plain attachment.

              This is all in the guise of making it easier for the client to render your message, which if your client is a perl script, you're like, thanks for nothing.

              I know jwz loves it when people get into pissing matches in his blog, so please, either take my word for it, or read again, really carefully.

              • injector says:

                I actually read the RFC before making my first post, but I went into it thinking that it was for the purpose I detailed. So the words seemed to be saying that to me.

                As ckd surmised I was actually thinking of message/partial. That's the one which does what I describe, and is recommended to be rejected outright.

                At least this pissing match (which I was hesitant to continue, but I was so sure I was right) was on the topic of MIME encoding.

            • ckd says:

              You're thinking of message/partial, not multipart/related.