Lisp, python, perl scripts programs would be covered by claims 1 and 2, which do not refer to XML at all. Here's a lisp script for example:
(defun foo()
"description of foo here"
(do something))
Hence Lisp seems to be prior art for claims 1 and 2. The Lisp 1 manual is dated 1963. I don't know if Lisp 1 included the documentation string, but by the 80's when I encountered Lisp the documentation string option was part of the language.
OK, claim 3: encode such a script in XML. woohoo. XML is obviously isomorphic to S-expressions, hence also copious prior art back to 1961 (S-expression paper).
The only thing that NAT buys you is the ability to have multiple machines behind one IP address.
If you want security for a single machine without any configuration, a transparent firewall would work without needing to do any address/port translation.
In an IPv6 network, I would like my provider to give me a/48 or/64 network, so that there is no need for NAT and the application entanglements it causes.
RMS claims that the FSF has not proprietary software on their systems. I can't believe that is true. Are they using an open source BIOS? Do their disk drives have open source firmware?
For that matter, why stop at free software? FSF should insist on using free hardware.
A couple of us at Compaq Cambridge Research Laboratory did the initial port of Blackdown.org JRE 1.3.1 to the iPAQ running Linux a year ago. Blackdown finished the port, ran JCK, and it is now available from blackdown.org.
With Reuters/Instinet, we demonstrated a trading application running on the iPAQ using Swing, wireless, etc. at Java on Wall Street at the World trade center. It was really cool to be able to take an app that they had debugged on J2SE on a Win2K desktop and have it run, unchanged, on a handheld. Startup of the application was a bit sluggish, but runtime performance was adequate.
In addition to Java2 Standard Edition, J2ME, waba, and Kaffe are also available on the iPAQ running Linux. There are some notes about Java on the iPAQ at http://www.handhelds.org/z/wiki/JavaOnIPAQ
Savaje: http://www.savaje.com/ has ported J2SE to the bare ipaq (using the bootldr from Compaq CRL). This version is reportedly quite fast.
If you prefer PocketPC, Insignia has J2ME available.
Studies of database performance show that the most effective way to speed up database access it to cache it in DRAM. I think google would be quite sluggish if the index was kept on disk.
One of the advantages that AltaVista had when it first came out was that the index was kept in DRAM. The servers at that time held 12GB of DRAM.
How long will it be before everyone carries computing clusters in their pockets, on their wrists, or in their cars?
It's not going to happen next month, but I think this is the future of computing.
In our research in the Mercury Project, we are exploring some of these ideas. Between the iPAQ handheld and the Mercury BackPAQ, we are building a device that will have simultaneous access to multiple wireless networks so that it can use the best available communications. It has a camera for taking pictures or for video conferencing. It has a headset jack so that we can explore speech-driven interfaces on handhelds. It has an accelerometer for gesture-driven interfaces. It has 32MB of flash for additional file storage.
The software side of the project is actually more interesting than the gadget side. That is where the action is. If you have to manually invoke ifconfig, iwconfig and route, then only the geeks are going to use these devices. We are going to have to develop systems (devices and infrastructure) that are much more advanced than the current ones. They need to be able to take care of themselves and to carry out what the user wants to do. We need to be able to tell our devices to "Make it so" and expect the right thing to happen. Now maybe I'm talking science fiction.
Some of the other comments are about applications. Although Moore's Law is helping us out with computation, memory, and disk space, we should not expect monolithic desktop applications to run on handheld devices. We would like to have componentized applications that adapt to the device they are running on, to the input and output devices being used, and to the available network connectivity.
Slashdot Mirror
I agree. Way trivial.
Lisp, python, perl scripts programs would be covered by claims 1 and 2, which do not refer to XML at all. Here's a lisp script for example:
(defun foo()
"description of foo here"
(do something))
Hence Lisp seems to be prior art for claims 1 and 2. The Lisp 1 manual is dated 1963. I don't know if Lisp 1 included the documentation string, but by the 80's when I encountered Lisp the documentation string option was part of the language.
OK, claim 3: encode such a script in XML. woohoo. XML is obviously isomorphic to S-expressions, hence also copious prior art back to 1961 (S-expression paper).
The only thing that NAT buys you is the ability to have multiple machines behind one IP address.
/48 or /64 network, so that there is no need for NAT and the application entanglements it causes.
If you want security for a single machine without any configuration, a transparent firewall would work without needing to do any address/port translation.
In an IPv6 network, I would like my provider to give me a
RMS claims that the FSF has not proprietary software on their systems. I can't believe that is true. Are they using an open source BIOS? Do their disk drives have open source firmware? For that matter, why stop at free software? FSF should insist on using free hardware.
A couple of us at Compaq Cambridge Research Laboratory did the initial port of Blackdown.org JRE 1.3.1 to the iPAQ running Linux a year ago. Blackdown finished the port, ran JCK, and it is now available from blackdown.org.
With Reuters/Instinet, we demonstrated a trading application running on the iPAQ using Swing, wireless, etc. at Java on Wall Street at the World trade center. It was really cool to be able to take an app that they had debugged on J2SE on a Win2K desktop and have it run, unchanged, on a handheld. Startup of the application was a bit sluggish, but runtime performance was adequate.
In addition to Java2 Standard Edition, J2ME, waba, and Kaffe are also available on the iPAQ running Linux. There are some notes about Java on the iPAQ at http://www.handhelds.org/z/wiki/JavaOnIPAQ
Savaje: http://www.savaje.com/ has ported J2SE to the bare ipaq (using the bootldr from Compaq CRL). This version is reportedly quite fast.
If you prefer PocketPC, Insignia has J2ME available.
Studies of database performance show that the most effective way to speed up database access it to cache it in DRAM. I think google would be quite sluggish if the index was kept on disk.
One of the advantages that AltaVista had when it first came out was that the index was kept in DRAM. The servers at that time held 12GB of DRAM.
It's not going to happen next month, but I think this is the future of computing.
In our research in the Mercury Project, we are exploring some of these ideas. Between the iPAQ handheld and the Mercury BackPAQ, we are building a device that will have simultaneous access to multiple wireless networks so that it can use the best available communications. It has a camera for taking pictures or for video conferencing. It has a headset jack so that we can explore speech-driven interfaces on handhelds. It has an accelerometer for gesture-driven interfaces. It has 32MB of flash for additional file storage.
The software side of the project is actually more interesting than the gadget side. That is where the action is. If you have to manually invoke ifconfig, iwconfig and route, then only the geeks are going to use these devices. We are going to have to develop systems (devices and infrastructure) that are much more advanced than the current ones. They need to be able to take care of themselves and to carry out what the user wants to do. We need to be able to tell our devices to "Make it so" and expect the right thing to happen. Now maybe I'm talking science fiction.
Some of the other comments are about applications. Although Moore's Law is helping us out with computation, memory, and disk space, we should not expect monolithic desktop applications to run on handheld devices. We would like to have componentized applications that adapt to the device they are running on, to the input and output devices being used, and to the available network connectivity.