Slashdot Mirror

POP3 clients (simple or advanced) do not following this "conversation" paradigm, and by not getting a copy of their own post two things happen: A) You have no confirmation the post made it to the list and B) you break threading on the email client because now people are responding to a message that never made it on my list.

The sad part is attempting to send yourself a copy of the message via CC: or BCC: does not work! Its like Gmail went out of its way to ensure you do not get a copy of your own post. Additionally while Google searching suggests there is an option to get yourself a copy of your own post, I was unable to find it anywhere.

I feel sorry for any of these people who are being switched over to Gmail's POP3 and are on mailing lists.

Others have written about the situation as well: Gmail + POP + mailing lists = broken

Burst.com claimed to have a revolutionary way of delivering streaming content. Lossless. Faster than realtime.

Well, golly. You can deliver content losslessly and faster than real time via HTTP and FTP, too. Only Burst.com did this with a magical, proprietary protocol that required a magical, proprietary server that they would be happy to sell to you. The secret of the "secret sauce" that Burst.com CEO Richard Lang mentions in the feature is that there is no secret sauce. ...

If you have a really fast conneciton and there are no bottlenecks along the way, it lets you see/hear media almost instantly. It works by putting a huge buffer at the client, and then filling that buffer as fast as possible so that buffering time is minimized.

QuickTime's "Fast Start" provided much of this functionality with QuickTime 3's progressive streaming (1998), and QuickTime 6 added the final missing piece (random access) with its Instant-On feature earlier this year. RealNetworks uses a similar method to optimize the viewing experience in RealSystem 9.

Burst has 10 U.S. patents, according to their own page here. It's hard to tell which ones are really at issue (I haven't seen a list of the ones Apple is trying to have invalidated) but it almost certainly includes 5,262,875 which in my reading is the most general one.

This is their main claim:

We claim:

1. An audio/video file server for decompressing and distributing selected audio/video program information stored in a compressed digital format within the file server to one or more external playback stations for real-time viewing by users at those playback stations, the audio/video file server comprising:

storage means for storing compressed digital audio/video program information;

transceiver means, connected to the storage means, for receiving compressed digital audio/video program information from an external source over a time period that is less than a real time period required to view the audio/video program information to thereby update the compressed digital audio/video program information stored in the storage means;

a plurality of playback units, each associated with an external playback line and an external playback station and each including decompression means, for receiving selected compressed digital audio/video program information stored in the storage means, for decompressing the selected compressed digital audio/video program information received from the storage means, and for playing the decompressed selected audio/video program information in real time over the associated playback line to the associated playback station;

network interface means, connected to the storage means, transceiver means, playback units, and plurality of playback stations, for receiving playback requests from the plurality of playback stations; and

processing means, connected to the storage means, transceiver means, playback units, and network interface means, the processing means being responsive to the network interface means, following receipt of a playback request, for controlling the associated playback unit to play the decompressed selected audio/video program information in real time.

To me, that's pre

Well, speaking only for myself, no.

Burst.com's patent -- at least according to Groklaw -- seems like it's definitely invalidated by prior art. According to this article, both Apple and Real (and possibly Microsoft) had their own versions of the same functionality, predating the patent by Burst.

Honestly the fact that Burst.com (or whatever company it was before it became Burst.com) produced a number of useful products doesn't matter a whit to the fact that they have a crummy patent that they're obviously trying to make a buck off of. That said, I can't blame them either -- the USPTO issued this piece of trash that they're trying to litigate, and there's no way that it's going to go away unless it gets invalidated by a judge.

The MS suit ended in what to me is a draw -- an out of court settlement where MS effectively bought Burst's cooperation. Apple doesn't have a history of doing that, so I think this time we'll see a resolution. Arguably MS's solution happened because Microsoft was under criticism for deleting evidence and not otherwise behaving fairly -- so saying that Burst's patent has been held in prior trials really doesn't wash.

I respect Burst as a company, but based on what I've read from the Microsoft and now the Apple case, they're a company on their last legs, looking to capitalize on a few shoddy patents that they managed to get issued while someone at the USPTO wasn't doing what ought to be their job: looking for prior art. If Apple wins and Burst goes out of business, I'll be slightly sad, but not terribly upset -- when a company sinks to the level of litigating obviously general patents, they have no place staying in business. The fact that they might have made real contributions to the art of computing in the past only makes the company's death more painful, but no less necessary, to everyone involved.

Oh here's some research -- from a former QuickTime Evangelist's Blog:

While I was Apple's QuickTime Evangelist, I was a magnet for all kinds of folks who claimed to have miraculous codecs and other holy-grail technologies. Burst.com claimed to have a revolutionary way of delivering streaming content. Lossless. Faster than realtime.

Well, golly. You can deliver content losslessly and faster than real time via HTTP and FTP, too. Only Burst.com did this with a magical, proprietary protocol that required a magical, proprietary server that they would be happy to sell to you. The secret of the "secret sauce" that Burst.com CEO Richard Lang mentions in the feature is that there is no secret sauce.

Mr. Lang believes that Microsoft was out to get him. However, the reality is that Burst.com was, at best, a fly to Microsoft's mountain.

Now Burst.com is suing Microsoft, a move apparently prompted by Windows Media 9's "Instant On" feature. If you have a really fast conneciton and there are no bottlenecks along the way, it lets you see/hear media almost instantly. It works by putting a huge buffer at the client, and then filling that buffer as fast as possible so that buffering time is minimized.

QuickTime's "Fast Start" provided much of this functionality with QuickTime 3's progressive streaming (1998), and QuickTime 6 added the final missing piece (random access) with its Instant-On feature earlier this year. RealNetworks uses a similar method to optimize the viewing experience in RealSystem 9.

Did somebody say something??

I can't hear you above the din of the consumer public's rushing to Apple solutions which aren't actually marketed as hubs but are doing nicely as hubs

Funny that... but then Apple sort of outlined the "digital hub" strategy at least as early as 2001, if not sooner. Sorry I don't have that quarterly report on hand. :)

Oh sure, we've heard noise from both Intel (ladies and gentlemen, the Ottoman PC) and Microsoft (how's this for a catchy name: Microsoft Plus! Digital Media Edition) before, but nothing delivered thus far delivers quality near the iLife suite + iPod (and maybe even a Mac Mini, or in my case an old laptop soon to be upgraded to a mini).

Ladies and gentlemen... the fat lady ain't about to sing on this one. Hold on, more FUD, vapor/promise/bloat/crash-ware is falling your way.

Burst.com is a penny stock company with no employees, no product and no discernible assets except a lawsuit against Microsoft, a company kept afloat by speculators --- gamblers --- in the lawsuit lottery game who believe a pot of gold lies at the end of that particlar rainbow. Burst.com's streaming snake oil

It must be true. I mean, after all pigs fly, fat lady has sung, and the cows have come home.

1. Apple are pushing AAC. Do you think that Apple fought tooth and nail to drag the MPEG group back to reality with their licensing terms so consumers could encode and stream MPEG-4 for free just to risk undermining it with another codec? Certainly not. Apple threw its hat in with MPEG.
2. Not a lot of people use Vorbis for their encoding. I know a few people who rip exclusively to Ogg Vorbis, but I'm a computer geek, and I work with computer geeks. Ask some college girl with a Christmas list for mommy and daddy if she gives a rat's ass that the iPod she wants doesn't support Ogg Vorbis.
3. The Ogg Vorbis spec does not include DRM. Apple are treading a very fine line with respect to DRM. Jobs managed to RDF the shit out of the record companies to get them to agree to the almost comically weak (compared to what we all know the RIAA would really rather have) DRM restrictions. The record companies want to see Apple supporting DRM, or else they're going to pull the plug. Apple can get away with supporting MP3 because it's only the most popular music format in the fucking world, but Vorbis doesn't have that excuse. You have to support MP3 if you want any chance of success. WAV has the excuse that no person in his right mind would listen to uncompressed audio on his iPod, since it defeats the whole "x,000 songs in your pocket," {x | x = 1, 2, 3, ...} mantra. Also, unless you like loading the equivalent of 10 MP3's into the player's RAM to play the WAV and thus reducing battery life, then who's going to put WAV on their iPod?

• The MPEG-4 Standard supports the possibility of DRM
• but it hasn't been implemented yet
• but they're working on it

The writers of the articles that /. mentioned have no idea what they're talking about. QuickTime 6 is not being adopted as a mobile phone standard -- MPEG-4 (as part of 3GPP) is. The writers basically just copied Apple's spin.

For the no-B.S. story, see the DoCoMo and MPEG-4 and QuickTime (oh my?) story from last week.