By the way... for the time being, I'd stay away from wireless networks. We tried that at the beginning and it was just a mess of problems... interference, poor response time, dropped packets...
You might just want to give wireless a look. You can get low end stuff (webgear cards, 1Mb, no macs) for about $160 for a two-pack. for about $160 per, you can get the lucent gold wavelan cards (11Mb, 128 bit encryption). if you've got a laptop but no wireless, you're really missing out - especially if you have a garden.
This is nothing compared to the hue and cry when I had to change SunSITE's ip address for the first time in years back in, what, 1995, 1996? You'd be astonished at the number of linux hackers who had hard-coded SunSITE's ip address into/etc/hosts just so they wouldn't have to query a name server before getting their Linux goodies, and were _really pissed off_ when they couldn't get to us anymore.
> I really think that one of the reasons that the > Perl modules are SO useful is due to the lack of > strong typing ala Java.
> A PERFECT example of this is the DBI library. In > Perl, it's simple. You can even do > ($id, $firstname, $lastname) =$sth->fetch_row();
> In Java, with the JDBC, you have to do this: > (assuming rs is a ResultSet object) > int id = rs.getInteger(1); > String firstname = rs.getString(2); > String lastname = rs.getString(3);
That's a very misleading argument. You're comparing the functionality offered by a 3rd party perl module with the functionality offered by the standard JVM. A better example would be to compare perl's DBI/D modules with, say, the castor project (http://castor.exolab.org/). Using castor, one can serialize complex objects to and from a SQL data source without doing all of the work by hand.
Two files share the same MD5 checksum only if they are absolutely identical (or you're really lucky!). Two mp3 files of the same song may be different even if they sound the same - if one original cd was slightly scratched, say, or if the two people used different encoders. Good idea, but MD5 isn't the way to do it.
Hiya. I'm one of the authors on the cocoon project and I admit my biases upfront. I think, and many of you seem to agree, that the web publishing industry (more generally, the electronic information publishing industry) is in desperate need of a standard way of seperating (and mixing) content and design. XML (a generic tree description language) and XSLT (a generic tree merging and transformation language) offer a very elegant way of accomlishing that goal. The cocoon project is currently focused mainly on two goals: creating (and implementing) a standard way to create XML fragments dynamically, and determining (and implementing) the best way to maintain a site back-ended by XML and XSLT. I encourage brave developers to come check it out - the basic stuff (XML+XSLT -> HTML) works very well, the more elaborate stuff (SQL,LDAP,POP3 -> XML+XSLT -> HTML) is coming along very well, and we're playing with a very interesting take on the whole *SP paradigm called XSP - I was personally highly skeptical at first but am beginning to see the light.
As far as IBM's product goes - once you drill down into the technical details, it looks very much like cocoon. Interestingly enough, some of the closed source components that IBM's product relies on were donated a few months back to jump start the xml.apache.org site (namely, the XML4J parser and the Lotus XSLT processor). The main thing that IBM seems to be offering here is its 'transcoder' technology - which may be interesting and certainly bears investigation, but for my money, you're better off checking out (and having a voice in the development of) the open source apache projects.
Slashdot Mirror
By the way... for the time being, I'd stay away from wireless networks. We tried that at the beginning and it was just a mess of problems... interference, poor response time, dropped packets...
You might just want to give wireless a look. You can get low end stuff (webgear cards, 1Mb, no macs) for about $160 for a two-pack. for about $160 per, you can get the lucent gold wavelan cards (11Mb, 128 bit encryption). if you've got a laptop but no wireless, you're really missing out - especially if you have a garden.
This is nothing compared to the hue and cry when I had to change SunSITE's ip address for the first time in years back in, what, 1995, 1996? You'd be astonished at the number of linux hackers who had hard-coded SunSITE's ip address into /etc/hosts just so they wouldn't have to query a name server before getting their Linux goodies, and were _really pissed off_ when they couldn't get to us anymore.
> I really think that one of the reasons that the > Perl modules are SO useful is due to the lack of > strong typing ala Java.
> A PERFECT example of this is the DBI library. In > Perl, it's simple. You can even do
> ($id, $firstname, $lastname) =$sth->fetch_row();
> In Java, with the JDBC, you have to do this:
> (assuming rs is a ResultSet object)
> int id = rs.getInteger(1);
> String firstname = rs.getString(2);
> String lastname = rs.getString(3);
That's a very misleading argument. You're comparing the functionality offered by a 3rd party perl module with the functionality offered by the standard JVM. A better example would be to compare perl's DBI/D modules with, say, the castor project (http://castor.exolab.org/). Using castor, one can serialize complex objects to and from a SQL data source without doing all of the work by hand.
Two files share the same MD5 checksum only if they are absolutely identical (or you're really lucky!). Two mp3 files of the same song may be different even if they sound the same - if one original cd was slightly scratched, say, or if the two people used different encoders. Good idea, but MD5 isn't the way to do it.
Hiya. I'm one of the authors on the cocoon project and I admit my biases upfront. I think, and many of you seem to agree, that the web publishing industry (more generally, the electronic information publishing industry) is in desperate need of a standard way of seperating (and mixing) content and design. XML (a generic tree description language) and XSLT (a generic tree merging and transformation language) offer a very elegant way of accomlishing that goal. The cocoon project is currently focused mainly on two goals: creating (and implementing) a standard way to create XML fragments dynamically, and determining (and implementing) the best way to maintain a site back-ended by XML and XSLT. I encourage brave developers to come check it out - the basic stuff (XML+XSLT -> HTML) works very well, the more elaborate stuff (SQL,LDAP,POP3 -> XML+XSLT -> HTML) is coming along very well, and we're playing with a very interesting take on the whole *SP paradigm called XSP - I was personally highly skeptical at first but am beginning to see the light.
As far as IBM's product goes - once you drill down into the technical details, it looks very much like cocoon. Interestingly enough, some of the closed source components that IBM's product relies on were donated a few months back to jump start the xml.apache.org site (namely, the XML4J parser and the Lotus XSLT processor). The main thing that IBM seems to be offering here is its 'transcoder' technology - which may be interesting and certainly bears investigation, but for my money, you're better off checking out (and having a voice in the development of) the open source apache projects.