No, it doesn't kill the "whole idea" but a long shot.
The "whole idea" was about making Flash sites more usable by enabling back/forward and history navigation in a Flash site using the browser's built in history management.
Considering that you can't bookmark pages within a Flash site regardless, you're not loosing anything (and actually gaining a significant usability enhancement) by using a hidden inline frame to activate automatic, cross-browser, cross-platform back/forward/history navigation within a Flash site.
And technically speaking, there are ways to get around the problem of deep bookmarking in a Flash file, but my original post was meant to be focused on the parent pointing out that there was no back/forward/history support for Flash sites.
You can implement full support of nearly every browser's native back/forward buttons within a Flash movie using just a hidden inline frame, a small hidden SWF that is loaded in the frame, a bit of JavaScript and a local connection between that SWF and your main SWF.
The main movie simply sends requests to the inline frame passing the current "page" in the Flash file via the querystring each time the user goes to a new section.
When then inline frame SWF loads, it sends a local connection request to "goto this page" based on what it recieves on the querystring.
The main movie intercepts the request and handles accordingly if it's a different page than the user is currently on.
Basically every time you go to a new section in the SWF issues a new page-load in the inline frame, the browser history management works as it would with individual files. The hidden SWF tells the main one where to go every time it loads.
To my knowledge this is the same basic principle of how Flex apps fully support the browser back/forward buttons. It works incredibly well and our clients are amazed and dumbfounded when we show this functionality in their Flash sites:)
The only thing it doesn't really allow for is bookmarking of individual pages.
If you'd like to look at some sample code, the Macromedia Pet Market App Blueprint (download the MX Front End for the sample FLA and HTML files) has this exact method implemented in it.
A couple of notes about using this method:
It requires Javascript so that you can add the querystring to the SWF embedding code of the hidden inline frame
If Javascript isn't available on the client, it will have no impact on the site (assuming you don't use JS to embed the main SWF). The inline frame will be loaded each page switch, but since it won't have the querystring data, clicking back/forward won't do anything to the main SWF
It's a good idea to use Javascript to generate unique local connection ids for each browser window and pass it to both SWFs, otherwise, if the user opens multiple copies of the same site in different windows, moving around in one will cause the other windows to also move around magically:D
It makes it much easier if you build your app so that a single function call is responsible for moving between sections of the site.
While you're at it, you can also make your Flash file allow deep linking by looking for querystring requests to specific pages (again, passed to the SWF via Javascript) and using your section switch function accordingly;)
I'll be using an operating system with advertisements while I surf the web full of advertisements in my advertising supported browser that constantly forces me to close advertising pop-up after pop-up. I'll also get to enjoy tons of personally delivered advertisements when I check my email in my advertising supported e-mail client, all while I enjoy my new personal favorite: advertising-bots that were automagically added to my advertising-supported instant messaging client.
Yes, it is useless. Besides the fact that Windows Media Player on OS X simply sucks, it also does not support all of the codecs, nor the DRM that the Windows version does.
I've been reporting this problem to Microsoft for years and it still remains subpar.
Of course, third-party players like mPlayer and VLC do better, but they cannot support the DRM'ed files either.
Magnet links are "an open URI-scheme and supporting practices/code for enabling seamless integration between websites and locally-running utilities, such as file-management tools." They are a URN rather than a URL in that it specifies what to search for rather than where to download from. See http://magnet-uri.sourceforge.net/ for more information and the spec.
A magnet link will never point to a torrent file, but it could specify a file hash for a torrent file that can be searched against.
It specifies what to search for. The href portion is "magnet:?xt=urn:sha1:YNCKHTQCWBTRNJIV4WNAE52SJUQCZ O5C". When clicked it will cause your P2P client to launch (if installed) and search for files whos SHA1 hash match the one provided.
It specifies a location to download the torrent from. The href portion is "http://torrent.dulug.duke.edu/torrents/stentz-binar y-x86_64.torrent". When clicked it will either download the torrent file via http or launch your torrent client and connect to the tracker server.
Why the hell was that moderated +5 insightful? It's so full of holes it isn't even funny.
"I don't believe there are any real (as in frequently used) legitimate reasons for P2P networks to exist other than to distribute material illegally.... I'm not saying that it's not possible to use P2P networks for legit reasons, and I'm not saying that on occasion people do obtain legal materials from them."
I run a community gaming site that catalogs maps for First Person Shooters. With over 10 GB of maps and growing, P2P combined with magnet links is an incredibly valuable method of file distribution that doesn't require loads of cash, server cycles and bandwidth to operate and maintain. It boasts hundreds of downloads a week. I'd hardly call that "occassional."
Really though, it's not a good way for an author to market something (no tracking, no content control, no targeting, etc), and it's not a convenient way for the consumer to retrieve something (file descriptors can be poor, you get queued up, you have to share back to get good rates with some services, etc).
No tracking, content control and targeting? Not convenient? You have to share back to get good rates? File descriptions are poor?
Any qualified web admin can implement tracking on the web site that's listing the download whether it be magnet, torrent or otherwise. As well, some P2P apps provide limited download tracking. BitTorrent on it's own does not provide tracking either (you'd have to analyze torrent downloads in the server log files), so your point is kind of moot.
Not convenient? Ever heard of a magnet link? You put a link on your page. Clicking it launches the user's P2P app and starts the download. How is that not convenient? On a comparison to BitTorrent I'd say it's just as, if not more convenient (I don't have to delete old torrent files with magnet links). Compared to HTTP downloads, all P2P tech is obviously less convenient since you have to download P2P software.
Share back to get good rates? Funny... that's how BitTorrent works and a good number of other P2P networks don't.
The one giant exception here is Bittorrent... encourages the distribution of *legitamate* content because it a) allows the author to create and maintain a torrent that isn't connected to some vast network of crap, b) torrents can be "distributed" via websites, which is where you want your consumer to be, c) the consumer gets faster downloads, d) the author pays for less bandwidth.
As I mentioned, magnet links eliminate the problems of the "vast network of crap." They contain a file hash similar to a torrent file and can contain one or more source seed server addresses. They can be put on a website just like any URL with the added benefit that they don't require you to have a one-to-one relationship of all your files to torrent files.
The fact that you even need to maintain and distribute torrent files is a pain. If I've got 4,000 files I want to distribute via BitTorrent, it requires that I maintain 4,000 torrent files. Granted, a software author may not have 4,000 files, but the requirement to maintain them still exists regardless.
The consumer only gets faster downloads with BitTorrent if they are able to get it configured and playing nice with their particular setup. Most, but not all, "average Joes" I've tried to sell BitTorrent on always complain about painful tweaking and crappy speeds because of it. This is primarily because BitTorrent requires you to upload back to the swarm, while others do not.
And a BitTorrent author only pays less for bandwidth if there are a large number of continually connected seeds and peers. If not, the
Yes, but she also says further into the discussion:
The important points to consider are that the co-branded version will be totally licence compliant (just as gurunet currently is), that its access will be totally opt-in (so you may choose not to use it at all), it keeps Wikipedia totally ads-free as many editors want it to stay, it generates revenues much needed to support our current amazing growth (and limit the number of times a fundraising drive notice will be visible on all pages), and finally, I hope we can use part of the revenues to create a special fund for development of our projects in some developing countries...
So I guess we really don't know what the real scoop is:)
Why do people think that sites like this -- that become immensly useful and popular -- can sustanin themselves without a steady revenue stream? A web site is not like TV or radio where you broadcast a signal over the air and any number of people can pick it up without killing your station.
I don't care how much time or effort anyone spent contributing content to the site. The fact is that SOMEONE has to pay to host that content and serve it to visitors.
From the Wiki FAQ:
"Previously, the site was hosted on the servers of Bomis, Inc, a company mostly owned by Jimmy Wales, who is currently the funder of part of the site's operational costs."
So Mr. Wales pays for part of the operational costs and the rest comes from donations and a few grants and sponsorships.
First quarter fund raising earned a miniscule $96,648.70 and if they did as well (surpassing their goal by 25%) every quarter, they'd still be $352,605.20 shy of the 2005 budget.
Given the very little bit I know from looking at this information, I don't see it being an easy task to survive during their continued growth without some kind of revenue generating system on the site -- whether it be ads or subscription.
As many have already pointed out, apps like Trillian and those based on GAIM will only be a solution as long as the IM networks allow clients other than their own to access their network. When they decide to close them, we'll resume the cat and mouse game of point releases to these apps in order to keep up with the networks... then you won't think it's such a great solution.
Slashdot Mirror
You should see the acrylic window I put on my old Tandy1000 EX's external 3 1/2 drive!
No, it doesn't kill the "whole idea" but a long shot.
The "whole idea" was about making Flash sites more usable by enabling back/forward and history navigation in a Flash site using the browser's built in history management.
Considering that you can't bookmark pages within a Flash site regardless, you're not loosing anything (and actually gaining a significant usability enhancement) by using a hidden inline frame to activate automatic, cross-browser, cross-platform back/forward/history navigation within a Flash site.
And technically speaking, there are ways to get around the problem of deep bookmarking in a Flash file, but my original post was meant to be focused on the parent pointing out that there was no back/forward/history support for Flash sites.
You can implement full support of nearly every browser's native back/forward buttons within a Flash movie using just a hidden inline frame, a small hidden SWF that is loaded in the frame, a bit of JavaScript and a local connection between that SWF and your main SWF.
Basically every time you go to a new section in the SWF issues a new page-load in the inline frame, the browser history management works as it would with individual files. The hidden SWF tells the main one where to go every time it loads.
To my knowledge this is the same basic principle of how Flex apps fully support the browser back/forward buttons. It works incredibly well and our clients are amazed and dumbfounded when we show this functionality in their Flash sites
The only thing it doesn't really allow for is bookmarking of individual pages.
If you'd like to look at some sample code, the Macromedia Pet Market App Blueprint (download the MX Front End for the sample FLA and HTML files) has this exact method implemented in it.
A couple of notes about using this method:
Have fun!
So THIS is really what went wrong with Lego Mindstorms... this guy has been stealing all the sets!
Hmm... so let me make sure I understand.
I'll be using an operating system with advertisements while I surf the web full of advertisements in my advertising supported browser that constantly forces me to close advertising pop-up after pop-up. I'll also get to enjoy tons of personally delivered advertisements when I check my email in my advertising supported e-mail client, all while I enjoy my new personal favorite: advertising-bots that were automagically added to my advertising-supported instant messaging client.
Yeah, it sounds great!
Where'd you think Peter Jackson got the star for his next film?
To play with his ding dong?
To find his friend Wing Wong?
To do a little sing song?
Yes, it is useless. Besides the fact that Windows Media Player on OS X simply sucks, it also does not support all of the codecs, nor the DRM that the Windows version does.
I've been reporting this problem to Microsoft for years and it still remains subpar.
Of course, third-party players like mPlayer and VLC do better, but they cannot support the DRM'ed files either.
No, a magnet link doesn't point to anything.
Magnet links are "an open URI-scheme and supporting practices/code for enabling seamless integration between websites and locally-running utilities, such as file-management tools." They are a URN rather than a URL in that it specifies what to search for rather than where to download from. See http://magnet-uri.sourceforge.net/ for more information and the spec.
A magnet link will never point to a torrent file, but it could specify a file hash for a torrent file that can be searched against.
This is a magnet link
It specifies what to search for. The href portion is "magnet:?xt=urn:sha1:YNCKHTQCWBTRNJIV4WNAE52SJUQC
This is a link to a torrent
It specifies a location to download the torrent from. The href portion is "http://torrent.dulug.duke.edu/torrents/stentz-bina
I run a community gaming site that catalogs maps for First Person Shooters. With over 10 GB of maps and growing, P2P combined with magnet links is an incredibly valuable method of file distribution that doesn't require loads of cash, server cycles and bandwidth to operate and maintain. It boasts hundreds of downloads a week. I'd hardly call that "occassional."
No tracking, content control and targeting? Not convenient? You have to share back to get good rates? File descriptions are poor?
Any qualified web admin can implement tracking on the web site that's listing the download whether it be magnet, torrent or otherwise. As well, some P2P apps provide limited download tracking. BitTorrent on it's own does not provide tracking either (you'd have to analyze torrent downloads in the server log files), so your point is kind of moot.
Not convenient? Ever heard of a magnet link? You put a link on your page. Clicking it launches the user's P2P app and starts the download. How is that not convenient? On a comparison to BitTorrent I'd say it's just as, if not more convenient (I don't have to delete old torrent files with magnet links). Compared to HTTP downloads, all P2P tech is obviously less convenient since you have to download P2P software.
Share back to get good rates? Funny... that's how BitTorrent works and a good number of other P2P networks don't.
As I mentioned, magnet links eliminate the problems of the "vast network of crap." They contain a file hash similar to a torrent file and can contain one or more source seed server addresses. They can be put on a website just like any URL with the added benefit that they don't require you to have a one-to-one relationship of all your files to torrent files.
The fact that you even need to maintain and distribute torrent files is a pain. If I've got 4,000 files I want to distribute via BitTorrent, it requires that I maintain 4,000 torrent files. Granted, a software author may not have 4,000 files, but the requirement to maintain them still exists regardless.
The consumer only gets faster downloads with BitTorrent if they are able to get it configured and playing nice with their particular setup. Most, but not all, "average Joes" I've tried to sell BitTorrent on always complain about painful tweaking and crappy speeds because of it. This is primarily because BitTorrent requires you to upload back to the swarm, while others do not.
And a BitTorrent author only pays less for bandwidth if there are a large number of continually connected seeds and peers. If not, the
Well... technically speaking, it does dispense a lot of cash right into George Lucass's walllet.
...before the the machine that is Google gains consciousness.
Personally, I welcome... oh nevermind.
Angela didn't say that, Anthere did. Blah. Need more coffee.
Yes, but she also says further into the discussion:
The important points to consider are that the co-branded version will be totally licence compliant (just as gurunet currently is), that its access will be totally opt-in (so you may choose not to use it at all), it keeps Wikipedia totally ads-free as many editors want it to stay, it generates revenues much needed to support our current amazing growth (and limit the number of times a fundraising drive notice will be visible on all pages), and finally, I hope we can use part of the revenues to create a special fund for development of our projects in some developing countries...
So I guess we really don't know what the real scoop is
Bandwidth is not free.
Why do people think that sites like this -- that become immensly useful and popular -- can sustanin themselves without a steady revenue stream? A web site is not like TV or radio where you broadcast a signal over the air and any number of people can pick it up without killing your station.
I don't care how much time or effort anyone spent contributing content to the site. The fact is that SOMEONE has to pay to host that content and serve it to visitors.
From the Wiki FAQ:
So Mr. Wales pays for part of the operational costs and the rest comes from donations and a few grants and sponsorships.
We're not talking a few hundred bucks a year and a single server running out of someone's in-home LAN closet. A total of $739,200 was budgeted for the 2005 calendar year alone, and that's not pocket change.
First quarter fund raising earned a miniscule $96,648.70 and if they did as well (surpassing their goal by 25%) every quarter, they'd still be $352,605.20 shy of the 2005 budget.
Given the very little bit I know from looking at this information, I don't see it being an easy task to survive during their continued growth without some kind of revenue generating system on the site -- whether it be ads or subscription.
Caring for what cows want -- very mooving.
You're killing me.
But we were having so much fun...
;)
/me closes thread
Okay okay, sorry. I couldn't resist (and technically you should have said "No more rhymes!"
Yeah, because you'll have nobody to talk to anyway. :)
As many have already pointed out, apps like Trillian and those based on GAIM will only be a solution as long as the IM networks allow clients other than their own to access their network. When they decide to close them, we'll resume the cat and mouse game of point releases to these apps in order to keep up with the networks ... then you won't think it's such a great solution.
The best IM clients IMO for OS X that have Jabber support (along with practically every other network) are Adium and Proteus (both of which use GAIM).
Like a whiny little boy ...
Yeah, the knowledge of "FORMAT C:
It must be an evil plot!