Regarding right clicking and saving torrents. I think it should save the
torrent, and associate it with mozilla, just like a you can save a bookmark to
the desktop. And launching it initiates the download.
(In reply to comment #9)
> I really don't feel comfortable with the idea that application/x-bittorrent
> files should react in a magical way.
>
> If we did this, the same result should happen whether you right-clicked on a
> link and saved it, clicked on the link and viewed it, or referred to it via an
> <img>, <object>, or background:url() syntax. This would leave no way to get at
> the real end of the link, which would arguably make us non-HTTP compliant, IMHO.
> It also seems fundamentally wrong to me. (It tickles my quality assurance "here
> be bugs" sense.)
I don't see how this is really any different than a SMIL file, or a .ram, or
.asx, .qt, etc. All of the above point to streams that don't use the HTTP
protocol (IIRC they all use RTSP).
The proposal, is just to do this internally, by beefing up the Download Manager
itself. Rather than launch another Application.
I think we should lobby for a torrent:// protocol. It's a good idea, and when
BitTorrent matures into a 2.0 protocol, may be wise.
Regarding the use in embedding, such as image tags... I don't see the point.
For most cases, torrents take a few seconds to transfer any data. The page
would most likely timeout anyway.
>
> Couldn't we implement moz-torrent: (or some other scheme in coordination with
> Bram Cohen) and simply have application/x-bittorrent offer to download the file
> "using the BitTorrent protocol"? (Just like looking at an application/
> octet-steam file should offer to "open the file in Mozilla" if it is really a
> text/html or image/png image.)
>
> Hmm. I need to think more about this.
There are a few questions I recieved, that I will address on my blog regarding
my idea, and reasoning.. perhaps later tonight or early this week.
I think Gerv covered most of it with his rather lengthy opening comments on the bug.
Bottom line: I think it should be treated only through the download manager.
Just download per the bittorrent protocol. A useful feature for the end user.
As Gerv states, content providers LOVE bittorrent. We will be seeing more, not
less of it. Mozilla has a silent history of being inovative, and *better*. I
think it's great to lead the way once again, and provide users with a feature
they can really use.
Regarding right clicking and saving torrents. I think it should save the
torrent, and associate it with mozilla, just like a you can save a bookmark to
the desktop. And launching it initiates the download.
(In reply to comment #9) x-bittorrent
> I really don't feel comfortable with the idea that application/
> files should react in a magical way.
>
> If we did this, the same result should happen whether you right-clicked on a
> link and saved it, clicked on the link and viewed it, or referred to it via an
> <img>, <object>, or background:url() syntax. This would leave no way to get at
> the real end of the link, which would arguably make us non-HTTP compliant, IMHO.
> It also seems fundamentally wrong to me. (It tickles my quality assurance "here
> be bugs" sense.)
I don't see how this is really any different than a SMIL file, or a .ram, or
.asx, .qt, etc. All of the above point to streams that don't use the HTTP
protocol (IIRC they all use RTSP).
The proposal, is just to do this internally, by beefing up the Download Manager
itself. Rather than launch another Application.
I think we should lobby for a torrent:// protocol. It's a good idea, and when
BitTorrent matures into a 2.0 protocol, may be wise.
Regarding the use in embedding, such as image tags... I don't see the point.
For most cases, torrents take a few seconds to transfer any data. The page
would most likely timeout anyway.
> x-bittorrent offer to download the file
> Couldn't we implement moz-torrent: (or some other scheme in coordination with
> Bram Cohen) and simply have application/
> "using the BitTorrent protocol"? (Just like looking at an application/
> octet-steam file should offer to "open the file in Mozilla" if it is really a
> text/html or image/png image.)
>
> Hmm. I need to think more about this.
I kicked off this round of BitTorrent debates a few days ago with this: robert. accettura. com/archives/ 000323. shtml
http://
There are a few questions I recieved, that I will address on my blog regarding
my idea, and reasoning.. perhaps later tonight or early this week.
I think Gerv covered most of it with his rather lengthy opening comments on the bug.
Bottom line: I think it should be treated only through the download manager.
Just download per the bittorrent protocol. A useful feature for the end user.
As Gerv states, content providers LOVE bittorrent. We will be seeing more, not
less of it. Mozilla has a silent history of being inovative, and *better*. I
think it's great to lead the way once again, and provide users with a feature
they can really use.