The speed at which they burn their CDs won't have any effect on quality. The real issue is the amount and care of their prep work before each concert, to make sure the feeds they're capturing are of a high quality. And they should be if they're patched into the same feeds that the concert speakers are getting, since they then get the benefits of the same volume levels and mixing that the concert guys put together.
Obviously, there will be no post-production editing or enhancing, so you're basically just buying a fancy bootleg, not a CD you'd buy from a store of a live performance. But it shouldn't suck too bad, and it'd sure beat holding up a mini-recorder in the crowd.
(probably a moot point, as I can't see the RIAA letting this happen - unless they're getting a healthy chunk out of the pie.)
Ok, slightly OT, and I doubt it's an original idea, but I wonder if it's possible for a mailer to have a "bounce" button that sends back a legitimate bounced-email response to any message you want. I imagine some spammers track bounces because they don't want to waste time/bandwidth/servers sending to obviously bad addresses.
Kind of like the "telemarketer zapper" or whatever that product is that puts the three standard "line disconnected" tones at the beginning of all your calls, so telemarketer's call-systems think your number is no longer valid.
(sure, wouldn't do a thing to all the spammers who forge their headers, but it may help a bit...)
I'm also pretty surprised to see this kind of sympathy for Windows newbs on this site.
True, I wouldn't expect many/.ers to fall for this (and I don't believe the claims it can install itself without confirmation, except perhaps on very old versions of IE).
However, I'm sure every/.er has family members, friends, coworkers, etc. who are Windows newbs, and since they're the ones who will get "infected" and come running for help, it's good for us/.er's to keep up on these things, so we can quickly diagnose and remove them.
(mind you, perhaps pleading ignorance can get you out of doing all these trivial tasks for friends and family - time to rethink my strategy...)
Depending on the typist, I can't see reading a book out loud as being any faster than transcribing it - especially considering that the speech recognition software is unlikely to do the proper punctuation, paragraph breaks, people & place names, and general capitalization, so proofing the results would take a considerable amount of time.
But as the GP said - a moot point since OCR'ing it and proofreading/fixing minor typos would be far quicker than either.
Unfortunately, some programs have found a work-around (Kazaa and even Kazaa-Lite come to mind) - they launch a little sub-process to fire up a browser that goes to a specific URL (with whatever details they want to U/L encoding in the URL as CGI args). And since most people who have firewalls still allow IE or Mozilla access through port 80, it gets through. The user may or may not notice a little pop-up window appear and disappear quickly.
Mod the parent up! I'd love to see this backfire on PCI-SIG by having someone build a similar database, complete with logos and names (but with perhaps a small disclaimer buried in lawyer speak at the bottom).
Also, someone should tell the poor Alan Deikman to forward all the hate-mails he's receiving on to the PCI-SIG folks. It'd be a shame for them not to hear them, as I imagine most people who did send them have moved on to the next/. story.
BTW, you can send yours through their website (true, an annoying little CGI form instead of a tangible email address, but better than nothing).
That is an interesting concept, but with modern equipment, I'd expect it to actually be slower than how it's done now.
The major bottleneck with today's browsing isn't (typically) the browser - it's first and foremost the network (especially with this article - a 56k modem!), and second is the server's capacity to handle traffic (not normally an issues until/. posts a link to it...).
Even on a slower computer, and a very complex web page with layer-upon-layer of embedded tables and javascript will still "render" in a matter of seconds - but to get a 50k uncompressed page over a 56kbps (~7kB/s) connection will take over 7 seconds (not including images, external scripts, etc). The reason everyone's so doubtful of any major improvement here is because it's highly unlikely for him to have modified how the modem works. (Now if the claim was that a page can be rendered 4 times faster, it's entirely possible).
Now the reason I think your suggestion would actually be slower is because of all the extra computation needed to dynamically check two pages for similarities, and therefore know which parts are new and which are old - in the best case, it's as if it's rendering the page twice (once with the old content, and then filling in the changed parts with new content, thereby forcing a recalculation of text wrapping, table sizes, etc, for each piece - plus the expense of doing the effective "patch"). It of course would become much worse if it needed to do this calculation on all pages in the cache, and not just the referring page.
Not to shoot down an interesting idea, mind you - I certainly encourage creative thinking for all computer problems. That's what discussion sites like this are all about, no? (ok, don't answer that...)
(ps. most modern browsers will indeed render a table before the ending tag, at least after a certain small timeout period - the reason you don't typically want to is because an unfinished table likely won't look a thing like it's supposed to.)
Although tracing back to the actual attackers can be very difficult, it can still be done with enough investigation and willpower. For an amusing tale of how a popular (although not always loved) windows security guy did just that, go here.
He basically got his hands on one of the "zombie" trojans the DDoS'ers use, reverse engineered it to find out how it works (and which IRC servers it talks to to receive its commands), wrote his own to connect to said server and waited until the attackers personally logged in. It really is a good read.
Correct me if I'm wrong, but FreeGuide uses XMLTV to scrape its listings from various internet sites (Zap2It for North America). The problem is that Zap2It is very aware of this package, and although they've been a little forgiving of it so far, their stance is very much that it's a problem they're going to have to deal with (either legally or technically, such as constantly changing the HTML format to make scraping that much harder). I've had discussions about this with Jay Brodsky, their Director of Technology, since I was using XMLTV to redistribute my local listings on the web.
Their problem is that they spend a lot of money to consolidate the tv schedules - and they offer it free on their site using the advertising model. When people scrape it for their own use, they're subverting the ads, and zap2it loses money instead of making it (bandwidth, servers, staff, syndication). It's a much larger problem because of the way XMLTV scrapes - hundreds, if not thousands of pages must be retrieved and parsed to get the complete schedule.
Now before you all scream anti-corporate statements, realize that if enough people "steal" their content, they'll simply shut it down, as no company (and no one) wants to lose money.
For an interesting previous thread on this very topic, check here.
... why not just change the log format to not include any personally trackable data (IP address, username, any cookie info, etc). Using Apache, this is very simple with the CustomLog directive.
Then you still have proper log files so you can create reports on traffic, bandwidth, and all the other goodies logs are intended for.
Yes, ATI was accused of cheating in one of their driver sets, and they did indeed do some "quackery". But since this happened, more and more people are looking for it, so I doubt any GFX card company would dare try it again.
But also keep in mind that optimizing for a specific game isn't necessarily a Bad Thing, so long as it doesn't hurt the visuals or quality. For example, if you know a certain game doesn't need/use certain features of the card, and by disabling them you improve performance, then why not. (ATI, however, vastly cut down on the texture quality in the game itself to get their increases - tsk tsk).
OutRigged was correct - there can be MASSIVE differences between driver revisions, and there typically is, which is why "leaked" betas are so wildly popular in the O/Cing crowd. I grab a new one every month or so, and although I may not see much of an improvement 4 out of 5 months, my benchmarks will suddendly leap up 10-20% (even NVidia claims the recent 40.x reference drivers are 25% faster than the 30.x). I also find the newer your card, the bigger the performance gains you typically see by upgrading the driver.
The reasons for a speed increase aren't always related to the graphics card itself, but can be due to the motherboard chipset, type of RAM, BIOS, or even a specific game or app itself. These tweaks will change how the card communicates with these in specific circumstances, which can be vary greatly between different consumers' machines.
Since the graphics card industry is hugely competitive right now, it's in their best interest to spend a lot of time tweaking their drivers to the max.
The reason consoles don't worry too much about it is because they have a standard set of hardware (read: one graphics card - no competing card that customers can benchmark against) that ALL game developers must work with. This also simplifies game development because they know the exact config and driver set that EVERY user will be using.
Even though I'm sure they COULD tweak the drivers (forgetting the expense of distributing a firmware patch), they'd prefer to leave the tweaking in the game code. Besides, you can't easily benchmark the various consoles against each other, whereas the graphics card folks for PCs know that every performance site and magazine is going to use the exact same hardware config and same game to test their card against all others.
Agreed, you still have to validate on the server end - but the JS validation is still very useful, as you said, for speeding up error reporting AND (more importantly) reducing load on the server, as the error can be corrected before returning the results, for people who DO leave JS enabled.
My point is that as more and more people turn JS off, a useful feature of modern browsers is removed.
From RFC 2616, Hypertext Transfer Protocol -- HTTP/1.1, section 15.6:
15.6 Authentication Credentials and Idle Clients
Existing HTTP clients and user agents typically retain authentication information indefinitely.
HTTP/1.1. does not provide a method for a server to direct clients to discard these cached credentials. This is a significant defect that requires further extensions to HTTP. [...]
(my emphasis)
Zope uses session cookies (as do most sites - mod_session in Apache, for example), meaning they have implemented a clever but common work-around. The browser will send the username/password for every single page after using basic authentication, but since Zope knows the Session ID for the client (stored in a cookie), it will intentionally respond with a "404 - Authentication Required" error when the user clicks on the logout button (meaning the browser thinks the username/password was wrong, thus clearing its local cache of said information). The problem is that the authentication is really based on the cookies, not the "standard, universal" authentication. Zope only uses Basic Authentication to get the initial username/password, and then relies on cookies thereafter.
I'm all for standards, but when they lack in basic funcationality, other methods must unfortunately be utilized.
(ps. I'm no Zope expert, so please correct me if I'm wrong and there's some hidden feature of HTTP I'm not aware of).
This is a user interface issue with the UA, nothing to do with HTTP authentication.
True, it's the choice of the UA - but until most of the browsers out there implements a feature like this, a web-developer simply can't rely on this feature being present, which means we are forced to "work around" it using pop-ups (or a completely separate page - which is more load to the server). And at the present, I'm not aware of a single browser that does implement an easy logout or forget username/password feature, making this a moot point.
[...] they break the UI the user is used to by breaking Back [...]
Also true, a pop-up removes the very useful back button. However, there are certain times in an interface cycle where a "back" feature doesn't make logical sense, or at least can be replaced with a more cognitive "cancel" button, such as:
Any "yes/no/cancel" dialog - the cancel basically acts as a back button, but by having a pop-up you can prevent the user having to do a complete HTTP request/response cycle, unnecessarily loading down both the server and client.
A pop-up explaining a problem with a users input in a form - it's a simple notification prompt, and requires only an acknowledgement (using a completely separate page is once again an
unnecessary request to the server)
Glossary definitions, where a word, when clicked, links to a small description.
Picture or short article viewer, where a thumb-nail/abstract list is displayed on the "main" page, but each click generates a small window with the full content.
As pointed out earlier these checks have to be done on the server end regardless, but web developers can eliminate a large percentage of extra "hits" on their server by having this check in a javascript pop-up, meaning their use has a valid purpose other than advertising.
I'm the first to admit the majority of sites using javascript are doing so in an unreputable way (pop-up/under ads, maximizing the browser, having unnecessary alert pop-ups, annoying scrolling status-bar messages, etc.), but my point is that there are perfectly valid and useful ways to use javascript to enhance the functionality of a site.
But we're seeing the same reaction to javascript as we are to email now - spam has ruined the purpose for which it was intended. In the case of email, whitelists are becoming the only sure-fire way to eliminate it, at the expense of extra hassle on the user end. And in the case of javascript/pop-ups, most people in the know are turning these features off, forcing web developers like myself to disregard the valid usefulness of these technologies.
Care to point out a single constructive use of popups?
How about a login/password box (and NOT using the antiquated HTTP method of authenication - for one, it has no way to "logout" a user). OR any quick dialog box that requires a yes/no/cancel interaction. OR one that validates user input (removing the slow interaction between server and client just to confirm they actually typed something useful into the text box)
Almost every executible GUI program we use today has many of these kinds of "pop-up" dialog boxes - some more complicated than others (from confirmation dialogs to config screens). And all of them serve a useful purpose.
I'm a firm believer that developing apps using HTTP/(X)HTML as an interface is a smart move, as opposed to writing an executible for a specific platform - since it is a true write-once, run-anywhere tech (well, access-anywhere, at least from as far as client access is concerned.) And there's no reason we, as web developers, shouldn't be able to use pop-up windows for web-enabled apps.
Just because commercial sites the world over have abused pop-(up|under)s, doesn't mean the technology itself is useless.
ps. - I realize Mozilla allows you to disable scripts from opening "unrequested" windows (ie. where any "window.open" call is ignored, unless it applies to link you just clicked), but for a complicated site with various domains (eg. secure/non-secure), or other complications, it still isn't a robust enough solution to those of use developing true web-enabled applications.
Turn off all javascript, sound, flash, shockwave, and other scripting techs... then you're safe. Oh, wait... then turn off all graphix & sound... then turn off that nasty CSS formatting most sites use nowadays (god I hate fonts)... then remove colors...
Weeeeee. We're in Surfin' Heaven! Nothin' like a B&W mono-spaced equally-formatted no-graphics page to inspire me...
Ok, maybe going a little too far... but these new methods of introducing dynamic content to an otherwise static medium actually CAN be useful, in the right hands.
In fact, all of them were developed with good intentions, and all can be used with purpose - it's just the few sockcuckers out there who take advantage of them that ruin it for the rest of us.
Yes, TVguide, zap2it, et al. sell those feeds for money (quite a bit, I hear), and certainly don't want people like me scraping their content. But they are all just middlemen.
The TV stations want their schedules to be known to as many people as possible, as that's the way they attract a larger audience (and hence ratings go up and they can charge more for advertising). Most offer their lineups on their own sites, with minimal advertising (typically they just advertise their own shows), but to scrape each of these individually would be a daunting task.
What's interesting about XMLTV is that the original author (IMHO) is more concerned with the XML file format than with actually scraping content. It's a full-featured and well-designed markup language for TV programs, and could/should become the defacto standard in disemmenating schedules. If some of the major networks were to offer this openly, and people like me began using it, I think it could catch on, with all tv stations jumping on the bandwagon. Then middlemen like TVguide would have to rethink their business model.
It's too bad information is so expensive... it doesn't have to be.
I respectfully disagree. Although securing things has typically made using it harder, there are certainly measure you can take to make it transparent to the user, SSL and SSH being the leading examples. Sure, they do little to secure the machines your talking to, but they virtually remove the fear that someone listening in on the conversation can see what you're doing (and as wireless tech becomes more popular, this kind of ease-of-use will be vastly more important).
Re:Open PVR just needs an open schedule...
on
Build Your Own Linux PVR
·
· Score: 4, Interesting
You're right, it is a problem - I built my own web-based TV listings page using XMLTV (just for where I live), but put it online. It didn't take zap2it.com (the North American provider that XMLTV scrapes from, not TVguide) long to find it and ban my IP.
However, XMLTV's message boards on SourceForge claim that zap2it's license agreement DOES allow for all sorts of personal use (just not public, like I did). But I'm sure as XMLTV's popularity grows, they'll start cracking down on its usage.
FYI, the tv_grab_na script hits their server once per day per channel - so if you want 14 days of programming, and have 50 channels, that's 700 rather-large, dynamic, HTML-ridden pages they have to serve - if a few thousand start doing this daily, they'll figure a way to shut it down in a hurry.
I do wish the TV stations would provide their own XML-based listings (SOAP?) - it'd certainly be in their best interests.
granted, this approach does open the door for more knowledgable blackhats to work on exploits...
You just answered your own question. EVERY piece of software over 100 lines of code has bugs, and a decent number of those bugs can be used to compromise a system. Both black-hatters and white-hatters are always on the lookout for these, but it's not like they're all banging away at the same chunk of code. When a vulnerability is found, it's typically just one coder out there who stumbled upon it.
But by even announcing that a hole has been found in a certain piece of software, you're giving a headstart to all the blackhatters, telling them where to start looking. If you can announce the hole and the patch at the same time, you at least give the sys admins ample opportunity to fix their machines before the bad guys figure out how to hack in.
Actually, having a flash-only site like that is very bad design, in several ways:
True, you don't see one page and have the rest fail, but I think that's better than seeing no page at all (like so many other posts have indicated upon the initial slashdotting).
You're forced to download every "page" in the flash animation, even if you only want to see one.
You can't judge the quality of the flash "site" until the entire thing's been downloaded.
It breaks the "back" button so many of us rely on - you're forced to use their concept of navigation.
There's no way to link or bookmark a specific page, destroying one of the greatest functionalities of the Net (mind you, some could argue this is a good thing, like those sites who don't WANT to be deep-linked).
Flash is not nearly as widely supported as plain old HTML on various platforms.
Profit! (sorry - it felt wrong to make a list on Slashdot without having this entry...)
Now, Flash can be useful, especially for animated comics and whatnot, but there's nothing at this site that requires it. The camera-panning can just as easily be accomplished with javascript (or even regular links, albeit they'd be a lot slower), and then if someone doesn't have javascript enabled, at least they still see the first frame.
Sorry for the rant - I'm just not a big fan of "fad" technologies that break away from the web standards so many are trying to push.
Slashdot Mirror
Obviously, there will be no post-production editing or enhancing, so you're basically just buying a fancy bootleg, not a CD you'd buy from a store of a live performance. But it shouldn't suck too bad, and it'd sure beat holding up a mini-recorder in the crowd.
(probably a moot point, as I can't see the RIAA letting this happen - unless they're getting a healthy chunk out of the pie.)
Kind of like the "telemarketer zapper" or whatever that product is that puts the three standard "line disconnected" tones at the beginning of all your calls, so telemarketer's call-systems think your number is no longer valid.
(sure, wouldn't do a thing to all the spammers who forge their headers, but it may help a bit...)
True, I wouldn't expect many /.ers to fall for this (and I don't believe the claims it can install itself without confirmation, except perhaps on very old versions of IE).
However, I'm sure every /.er has family members, friends, coworkers, etc. who are Windows newbs, and since they're the ones who will get "infected" and come running for help, it's good for us /.er's to keep up on these things, so we can quickly diagnose and remove them.
(mind you, perhaps pleading ignorance can get you out of doing all these trivial tasks for friends and family - time to rethink my strategy...)
But as the GP said - a moot point since OCR'ing it and proofreading/fixing minor typos would be far quicker than either.
Unfortunately, some programs have found a work-around (Kazaa and even Kazaa-Lite come to mind) - they launch a little sub-process to fire up a browser that goes to a specific URL (with whatever details they want to U/L encoding in the URL as CGI args). And since most people who have firewalls still allow IE or Mozilla access through port 80, it gets through. The user may or may not notice a little pop-up window appear and disappear quickly.
Also, someone should tell the poor Alan Deikman to forward all the hate-mails he's receiving on to the PCI-SIG folks. It'd be a shame for them not to hear them, as I imagine most people who did send them have moved on to the next /. story.
BTW, you can send yours through their website (true, an annoying little CGI form instead of a tangible email address, but better than nothing).
The major bottleneck with today's browsing isn't (typically) the browser - it's first and foremost the network (especially with this article - a 56k modem!), and second is the server's capacity to handle traffic (not normally an issues until /. posts a link to it...).
Even on a slower computer, and a very complex web page with layer-upon-layer of embedded tables and javascript will still "render" in a matter of seconds - but to get a 50k uncompressed page over a 56kbps (~7kB/s) connection will take over 7 seconds (not including images, external scripts, etc). The reason everyone's so doubtful of any major improvement here is because it's highly unlikely for him to have modified how the modem works. (Now if the claim was that a page can be rendered 4 times faster, it's entirely possible).
Now the reason I think your suggestion would actually be slower is because of all the extra computation needed to dynamically check two pages for similarities, and therefore know which parts are new and which are old - in the best case, it's as if it's rendering the page twice (once with the old content, and then filling in the changed parts with new content, thereby forcing a recalculation of text wrapping, table sizes, etc, for each piece - plus the expense of doing the effective "patch"). It of course would become much worse if it needed to do this calculation on all pages in the cache, and not just the referring page.
Not to shoot down an interesting idea, mind you - I certainly encourage creative thinking for all computer problems. That's what discussion sites like this are all about, no? (ok, don't answer that...)
(ps. most modern browsers will indeed render a table before the ending tag, at least after a certain small timeout period - the reason you don't typically want to is because an unfinished table likely won't look a thing like it's supposed to.)
Dave Bowman: Open the pod bay doors, HAL.
HAL: I'm sorry Dave, I'm afraid I can't do that.
He basically got his hands on one of the "zombie" trojans the DDoS'ers use, reverse engineered it to find out how it works (and which IRC servers it talks to to receive its commands), wrote his own to connect to said server and waited until the attackers personally logged in. It really is a good read.
Their problem is that they spend a lot of money to consolidate the tv schedules - and they offer it free on their site using the advertising model. When people scrape it for their own use, they're subverting the ads, and zap2it loses money instead of making it (bandwidth, servers, staff, syndication). It's a much larger problem because of the way XMLTV scrapes - hundreds, if not thousands of pages must be retrieved and parsed to get the complete schedule.
Now before you all scream anti-corporate statements, realize that if enough people "steal" their content, they'll simply shut it down, as no company (and no one) wants to lose money.
For an interesting previous thread on this very topic, check here.
Then you still have proper log files so you can create reports on traffic, bandwidth, and all the other goodies logs are intended for.
But also keep in mind that optimizing for a specific game isn't necessarily a Bad Thing, so long as it doesn't hurt the visuals or quality. For example, if you know a certain game doesn't need/use certain features of the card, and by disabling them you improve performance, then why not. (ATI, however, vastly cut down on the texture quality in the game itself to get their increases - tsk tsk).
The reasons for a speed increase aren't always related to the graphics card itself, but can be due to the motherboard chipset, type of RAM, BIOS, or even a specific game or app itself. These tweaks will change how the card communicates with these in specific circumstances, which can be vary greatly between different consumers' machines.
Since the graphics card industry is hugely competitive right now, it's in their best interest to spend a lot of time tweaking their drivers to the max.
The reason consoles don't worry too much about it is because they have a standard set of hardware (read: one graphics card - no competing card that customers can benchmark against) that ALL game developers must work with. This also simplifies game development because they know the exact config and driver set that EVERY user will be using.
Even though I'm sure they COULD tweak the drivers (forgetting the expense of distributing a firmware patch), they'd prefer to leave the tweaking in the game code. Besides, you can't easily benchmark the various consoles against each other, whereas the graphics card folks for PCs know that every performance site and magazine is going to use the exact same hardware config and same game to test their card against all others.
Does this mean hand-writing-recognition has reached a huge milestone to actually understand what the doctor writes?
My point is that as more and more people turn JS off, a useful feature of modern browsers is removed.
D'oh! Figures - try to be smart, and screw up the link... Here's the correct RFC link (the RFC number 2616 was correct).
Zope uses session cookies (as do most sites - mod_session in Apache, for example), meaning they have implemented a clever but common work-around. The browser will send the username/password for every single page after using basic authentication, but since Zope knows the Session ID for the client (stored in a cookie), it will intentionally respond with a "404 - Authentication Required" error when the user clicks on the logout button (meaning the browser thinks the username/password was wrong, thus clearing its local cache of said information). The problem is that the authentication is really based on the cookies, not the "standard, universal" authentication. Zope only uses Basic Authentication to get the initial username/password, and then relies on cookies thereafter.
I'm all for standards, but when they lack in basic funcationality, other methods must unfortunately be utilized.
(ps. I'm no Zope expert, so please correct me if I'm wrong and there's some hidden feature of HTTP I'm not aware of).
- Any "yes/no/cancel" dialog - the cancel basically acts as a back button, but by having a pop-up you can prevent the user having to do a complete HTTP request/response cycle, unnecessarily loading down both the server and client.
- A pop-up explaining a problem with a users input in a form - it's a simple notification prompt, and requires only an acknowledgement (using a completely separate page is once again an
unnecessary request to the server)
- Glossary definitions, where a word, when clicked, links to a small description.
- Picture or short article viewer, where a thumb-nail/abstract list is displayed on the "main" page, but each click generates a small window with the full content.
As pointed out earlier these checks have to be done on the server end regardless, but web developers can eliminate a large percentage of extra "hits" on their server by having this check in a javascript pop-up, meaning their use has a valid purpose other than advertising.I'm the first to admit the majority of sites using javascript are doing so in an unreputable way (pop-up/under ads, maximizing the browser, having unnecessary alert pop-ups, annoying scrolling status-bar messages, etc.), but my point is that there are perfectly valid and useful ways to use javascript to enhance the functionality of a site.
But we're seeing the same reaction to javascript as we are to email now - spam has ruined the purpose for which it was intended. In the case of email, whitelists are becoming the only sure-fire way to eliminate it, at the expense of extra hassle on the user end. And in the case of javascript/pop-ups, most people in the know are turning these features off, forcing web developers like myself to disregard the valid usefulness of these technologies.
Almost every executible GUI program we use today has many of these kinds of "pop-up" dialog boxes - some more complicated than others (from confirmation dialogs to config screens). And all of them serve a useful purpose.
I'm a firm believer that developing apps using HTTP/(X)HTML as an interface is a smart move, as opposed to writing an executible for a specific platform - since it is a true write-once, run-anywhere tech (well, access-anywhere, at least from as far as client access is concerned.) And there's no reason we, as web developers, shouldn't be able to use pop-up windows for web-enabled apps.
Just because commercial sites the world over have abused pop-(up|under)s, doesn't mean the technology itself is useless.
ps. - I realize Mozilla allows you to disable scripts from opening "unrequested" windows (ie. where any "window.open" call is ignored, unless it applies to link you just clicked), but for a complicated site with various domains (eg. secure/non-secure), or other complications, it still isn't a robust enough solution to those of use developing true web-enabled applications.
Weeeeee. We're in Surfin' Heaven! Nothin' like a B&W mono-spaced equally-formatted no-graphics page to inspire me...
Ok, maybe going a little too far... but these new methods of introducing dynamic content to an otherwise static medium actually CAN be useful, in the right hands.
In fact, all of them were developed with good intentions, and all can be used with purpose - it's just the few sockcuckers out there who take advantage of them that ruin it for the rest of us.
The TV stations want their schedules to be known to as many people as possible, as that's the way they attract a larger audience (and hence ratings go up and they can charge more for advertising). Most offer their lineups on their own sites, with minimal advertising (typically they just advertise their own shows), but to scrape each of these individually would be a daunting task.
What's interesting about XMLTV is that the original author (IMHO) is more concerned with the XML file format than with actually scraping content. It's a full-featured and well-designed markup language for TV programs, and could/should become the defacto standard in disemmenating schedules. If some of the major networks were to offer this openly, and people like me began using it, I think it could catch on, with all tv stations jumping on the bandwagon. Then middlemen like TVguide would have to rethink their business model.
It's too bad information is so expensive... it doesn't have to be.
I respectfully disagree. Although securing things has typically made using it harder, there are certainly measure you can take to make it transparent to the user, SSL and SSH being the leading examples. Sure, they do little to secure the machines your talking to, but they virtually remove the fear that someone listening in on the conversation can see what you're doing (and as wireless tech becomes more popular, this kind of ease-of-use will be vastly more important).
However, XMLTV's message boards on SourceForge claim that zap2it's license agreement DOES allow for all sorts of personal use (just not public, like I did). But I'm sure as XMLTV's popularity grows, they'll start cracking down on its usage.
FYI, the tv_grab_na script hits their server once per day per channel - so if you want 14 days of programming, and have 50 channels, that's 700 rather-large, dynamic, HTML-ridden pages they have to serve - if a few thousand start doing this daily, they'll figure a way to shut it down in a hurry.
I do wish the TV stations would provide their own XML-based listings (SOAP?) - it'd certainly be in their best interests.
But by even announcing that a hole has been found in a certain piece of software, you're giving a headstart to all the blackhatters, telling them where to start looking. If you can announce the hole and the patch at the same time, you at least give the sys admins ample opportunity to fix their machines before the bad guys figure out how to hack in.
- True, you don't see one page and have the rest fail, but I think that's better than seeing no page at all (like so many other posts have indicated upon the initial slashdotting).
- You're forced to download every "page" in the flash animation, even if you only want to see one.
- You can't judge the quality of the flash "site" until the entire thing's been downloaded.
- It breaks the "back" button so many of us rely on - you're forced to use their concept of navigation.
- There's no way to link or bookmark a specific page, destroying one of the greatest functionalities of the Net (mind you, some could argue this is a good thing, like those sites who don't WANT to be deep-linked).
- Flash is not nearly as widely supported as plain old HTML on various platforms.
- Profit! (sorry - it felt wrong to make a list on Slashdot without having this entry...)
Now, Flash can be useful, especially for animated comics and whatnot, but there's nothing at this site that requires it. The camera-panning can just as easily be accomplished with javascript (or even regular links, albeit they'd be a lot slower), and then if someone doesn't have javascript enabled, at least they still see the first frame.Sorry for the rant - I'm just not a big fan of "fad" technologies that break away from the web standards so many are trying to push.