Let's get this idea out so that it gets implemented and leads to the decentralization of the DNS process...
An approach that is currently in development is Namecoin. It's a decentralized DNS approach based on Bitcoin. Names are registered and stored in the namecoin blockchain. More information is available at the dot-bit project website. Currently the software is there for registering and looking up names. What's needed is easier to use software like browser plugins and DNS proxies that lookup via namecoin. Some of this is in progress like the proxy, DNS and whois capability provided by namecoin.us.
BitCoin's creator and it's forum members don't want to be associated with WikiLeaks for fear of becoming associated with money laundering, so why is this article pushing it?
That's not completely correct IMHO. Many forum members have no problems with Bitcoin being used by groups like WikiLeaks. The reasons for those who don't want them to use it vary but the most common I've seen is that they're worried that it's too soon for Bitcoin. There may be implementation issues or existing limits in Bitcoin that are large influx of users would make it difficult to fix or workaround. For these reasons some members seem to be preferring a slow and cautious approach to promoting Bitcoin.
Have you tried using tinyvid.tv. It uses Ogg Theora, using HTML 5 video, will fallback to the Java Cortado applet to play the video if the browser doesn't support HTML5.
Correct me if I'm wrong, but isn't x264 an encoder, not a decoder? x264 implements h.264 which requires patent licensing. So even if the code is open, using it requires payments. How is that more open than Theora?
On the decoding front, what options are there for h.264? ffmpeg, but again that has licensing issues.
Reading the specs on Internet Channel it appears that it currently does not support it. Opera were the first to propose and implement support for so hopefully that and its companion will be included one day.
An idea would be to have Firefox, or other browsers, provide the necessary APIs (by implementing standards like the WHATG ones) to implement the bits of Google Gear that they need the plugin for. Then it becomes possible to use Google Gears without a download for those browsers that support those APIs.
Re:Can AJAX finally bring us "push technology"
on
Ajax in Action
·
· Score: 1
I think AJAX would just be another tool used to build portlets. The idea being that an individual portlet can use AJAX to make requests to the server and update parts of the portlet without the entire portlet having to be updated.
I'm not sure how portlet containers behave in the way they update the page though. When a portlet needs to be updated does the whole page update? Or do JSR-168 portals use AJAX behind the scenes to only update the specific portlets? From the looks of the spec it seems that AJAX could be a useful tool for portlets. At the very least, they'd be useful for writing the portal, which aggregates the portlets.
Re:Can AJAX finally bring us "push technology"
on
Ajax in Action
·
· Score: 3, Informative
Yes and No. One approach is to use have the client initiate an AJAX request to the server but the server does not send data immediately. It delays until there is stuff to push. It can either continue to push as needed (I send Java which gets evaled by the client) or it can close the connection and have the client re-connect. It then goes back to the delayed response.
This is better than client polling in that it's not so bandwidth unfriendly. It has the downside that browsers only have a limited number of connections that it uses and this eats one of them up (Some versions of IE only use 2 connections). This could prevent other AJAX or normal HTTP requests from occurring.
The same problem exists with the 'hidden IFRAME' approach. One interesting workaround is to have a hidden flash applet on the page whose sole purpose is to create a persistent connection to the server. The server can send data to the flash applet which then calls javascript callbacks on the web page. This does not eat up a browser connection as flash has its own connection pool. As it's a normal socket you can also use any protocol for the events you want. The downside is that if the user goes through a strict firewall that only allows outgoing http traffic on port 80 you're stuck.
Paul Colton, the author of the AFLAX library, implemented the persistent socket idea here: AFLAX and Persistent Connections. It uses AFLAX which allows easy communication from Javascript to an embedded flash applet.
The approach I've gone for is to use the flash idea, falling back to a delayed AJAX call response, then to a hidden IFRAME depending on browser support. This approach does what you want - allowing the server to push to the client.
For those interested in exploring Dylan, the Gwydion Dylan group have recently released 'Open Dylan'. This was once a commercial Dylan development environment and has been open sourced. The Gwydion Dylan maintaners have been working on making it available. They also have the Gwydion Dylan open source compiler which makes for two very strong open source Dylan implementations:
http://www.gwydiondylan.org/
It would be helpful both for wireless play from DS to DS as well as tunnelling. It also would open up some interesting application ideas for passing data between PC's and the DS of course. PDA applications with 'syncing' to the PC, etc.
Slashdot Mirror
Let's get this idea out so that it gets implemented and leads to the decentralization of the DNS process...
An approach that is currently in development is Namecoin. It's a decentralized DNS approach based on Bitcoin. Names are registered and stored in the namecoin blockchain. More information is available at the dot-bit project website. Currently the software is there for registering and looking up names. What's needed is easier to use software like browser plugins and DNS proxies that lookup via namecoin. Some of this is in progress like the proxy, DNS and whois capability provided by namecoin.us.
BitCoin's creator and it's forum members don't want to be associated with WikiLeaks for fear of becoming associated with money laundering, so why is this article pushing it?
That's not completely correct IMHO. Many forum members have no problems with Bitcoin being used by groups like WikiLeaks. The reasons for those who don't want them to use it vary but the most common I've seen is that they're worried that it's too soon for Bitcoin. There may be implementation issues or existing limits in Bitcoin that are large influx of users would make it difficult to fix or workaround. For these reasons some members seem to be preferring a slow and cautious approach to promoting Bitcoin.
It is not blocking 1.9.2 and will not be in Firefox 3.6, sorry. Unless FF 3.6 is delayed significantly.
Have you tried using tinyvid.tv. It uses Ogg Theora, using HTML 5 video, will fallback to the Java Cortado applet to play the video if the browser doesn't support HTML5.
Correct me if I'm wrong, but isn't x264 an encoder, not a decoder? x264 implements h.264 which requires patent licensing. So even if the code is open, using it requires payments. How is that more open than Theora? On the decoding front, what options are there for h.264? ffmpeg, but again that has licensing issues.
Reading the specs on Internet Channel it appears that it currently does not support it. Opera were the first to propose and implement support for so hopefully that and its companion will be included one day.
In browsers that support the HTML 5 audio element this will be possible.
An idea would be to have Firefox, or other browsers, provide the necessary APIs (by implementing standards like the WHATG ones) to implement the bits of Google Gear that they need the plugin for. Then it becomes possible to use Google Gears without a download for those browsers that support those APIs.
I think AJAX would just be another tool used to build portlets. The idea being that an individual portlet can use AJAX to make requests to the server and update parts of the portlet without the entire portlet having to be updated.
I'm not sure how portlet containers behave in the way they update the page though. When a portlet needs to be updated does the whole page update? Or do JSR-168 portals use AJAX behind the scenes to only update the specific portlets? From the looks of the spec it seems that AJAX could be a useful tool for portlets. At the very least, they'd be useful for writing the portal, which aggregates the portlets.
Yes and No. One approach is to use have the client initiate an AJAX request to the server but the server does not send data immediately. It delays until there is stuff to push. It can either continue to push as needed (I send Java which gets evaled by the client) or it can close the connection and have the client re-connect. It then goes back to the delayed response.
This is better than client polling in that it's not so bandwidth unfriendly. It has the downside that browsers only have a limited number of connections that it uses and this eats one of them up (Some versions of IE only use 2 connections). This could prevent other AJAX or normal HTTP requests from occurring.
The same problem exists with the 'hidden IFRAME' approach. One interesting workaround is to have a hidden flash applet on the page whose sole purpose is to create a persistent connection to the server. The server can send data to the flash applet which then calls javascript callbacks on the web page. This does not eat up a browser connection as flash has its own connection pool. As it's a normal socket you can also use any protocol for the events you want. The downside is that if the user goes through a strict firewall that only allows outgoing http traffic on port 80 you're stuck.
I describe some of the options here: More on Ajax and Server Push
Paul Colton, the author of the AFLAX library, implemented the persistent socket idea here: AFLAX and Persistent Connections. It uses AFLAX which allows easy communication from Javascript to an embedded flash applet.
The approach I've gone for is to use the flash idea, falling back to a delayed AJAX call response, then to a hidden IFRAME depending on browser support. This approach does what you want - allowing the server to push to the client.
For those interested in exploring Dylan, the Gwydion Dylan group have recently released 'Open Dylan'. This was once a commercial Dylan development environment and has been open sourced. The Gwydion Dylan maintaners have been working on making it available. They also have the Gwydion Dylan open source compiler which makes for two very strong open source Dylan implementations: http://www.gwydiondylan.org/
It would be helpful both for wireless play from DS to DS as well as tunnelling. It also would open up some interesting application ideas for passing data between PC's and the DS of course. PDA applications with 'syncing' to the PC, etc.