No Safari timeout (posted in April) points to a widget to slap Safari around and cure the stringent 60-second timeout that is inbuilt in the thing.

This comes up because, as increasing numbers of folks are realizing, the default architecture of MT is begining to display an inherent performance limitation as blogs age and the program has to cope with numbers of entries and files in the thousands.

No extra credit will be given for guessing the priority solving this will be assigned chez SixApart.

UPDATE: Okay, so maybe it’ll get discussed. But don’t tell the money boys, kids! It’ll give an existing consumer base one less reason to climb aboard the upgrade if you fix the bug!

3 thoughts on “No Safari timeout

  1. I don’t think it’s necessarily fair to phrase it that way… We’ve been pretty good about fixing bugs as they arise, and companies like are dealing with entries and files well into the tens and hundreds of thousands.

    I’d guess the most likely culprit for a slowdown, if you’re running with sufficient hardware, is an overly complicated template or one that relies on a slow plugin. There are times when you get to a certain number of entries and optimizations in templates are needed, but it’s not an inherent speed problem with MT.

  2. LOL, no offense intended, Anil. It does seem like a pretty clear engineering decision in support of marketing objectives.

    I’m running on very old hardware, a ’98 g3 Wallstreet. Onet the record set expanded beyond a given point, boom, slowdown. Follow the links in the initial entry to the forums.

    Also: you’re fingerpointing at the end user.

    But really, I’m not being a meanie, just expressing a realistic assessment. If I were managing dev for youguys there would have to be a revenue-generating reason to even LOOK for a solution to the problem.

    As you point out, it’s not a bug.

    (adding the Safari-timeout killer helped, though.)

Comments are now closed.