You're looking at three main bits to get the whole thing up and running:
The body - motors, gears, etc
The electronics - basic concepts, sensors, motor drivers, and if you get into more complex stuff, computerish things like microcontrollers
The software - basic AI
(obviously there's some overlap here)
If you have limited experience with these things, a kit from somewhere like Lego or Fischertechnik is an excellent place to start. These will take care of the hard stuff, letting you get straight in. Its also a good way to test the waters - see if you really want to get into robotics (it can become addictive and expensive very quickly).
If you want to do it yourself, I recommend these books by David Cook:
I tend not to get into the body building much, preferring off-the-shelf stuff. Basic Lego Technic sets have served me well, and I'm currently using Tamiya gearboxes and bases. I'm far more interested in the computer side, building small microcontroller-based computers and writing the software from scratch.
Correct. iPlanet MS (the 5.x series) used the NMS message store and IMAP/POP/HTTP servers (which, as you say, were once Cyrus IMAP), and included PMDF as the MTA (I believe iPlanet bought InnoSoft to get it).
After iPlanet split, we got NMS 6.0 and Sun ONE MS 6.0. ONE became JES, which is doing some hairy integration stuff with Sun's calendar, directory and web server (we're still on iMS 5.2 where I work, and its getting harder and harder to upgrade).
As far as I know, there's nothing of SIMS in iMS/ONE MS/JES MS (thank goodness - it was the pits).
What I'm wondering, is where is Netscape's version of the code? My interest in it is purely selfish - if I had it I could fix the issues we currently have with iMS, and I could stop implementing really awful workarounds and/or rewriting parts of the MTA to do my bidding.
Where are the other bits of software that once was Netscape Suitespot?
Netscape Calendar was not actually developed by Netscape, but was a version of CS&T's CorporateTime system. CS&T later renamed to Steltor, and is now part of Oracle, CorporateTime forming a large part of their colloboration suite.
Both Netscape and Sun got copies of everything when iPlanet split. Sun still develops and sells them, first as Sun ONE, now as Java Enterprise System. Netscape tried to keep development going for a while, but it kind of stagnated (much in the same way that the Netscape browser stopped moving after the AOL aquisition).
So where is the other Netscape software? I'm mostly talking about Messaging Server, which is an awesome piece of software, and Collabra Server, which.. isn't. Presumably they're still kicking around in a CVS in the depths of AOL somewhere. Anybody else know anything?
I had a look at Jabber years ago, but what put me off what is now known as XMPP was that it didn't solve the problem of framing stanzas. The only way to determine the borders of a stanza, and thus when you have read enough to successfully parse it, was by parsing the content.
The bulk of the discussion we had about framing
Thes links constitute the bulk of the discussion we had about framing a couple of years ago:
Basically, the simple framing we were considering (for backwards-compatibility reasons) might have made implementations easier under certain circumstances but also introduced issues (misframing).
How would you go about designing a multiplexing implementation that can handle, say, 1000 connections on a 800Mhz P3 without burning a lot of CPU?
As it stands, its quite straightforward to design a high-performance Jabber server that can handle many connections. Several folks (including myself) have done it.
Most implementations use an off-the-shelf callback-based XML parser (eg Expat or a SAX-based parser). When you get a read event on a connection, you read as much is there, and feed it into the parser. The parser fires callbacks, and you process the data contained in the XML. This all runs out of a normal descriptor readiness loop (select(), poll(), that sort of thing).
CPU time is kept as minimal is possible. We are parsing XML, so its always going to take a little more effort than a binary protocol (though modern parsers are pretty efficient, and there's ways to improve it if we're willing to write a custom parser that binds tightly to the network layer - zero-copy tricks, etc).
On the memory side, Expat in particular is pretty efficient - once its finished with an element, it gets cleaned up. So while its idling, the only state its holding is the top element and its namespaces.
Obviously, there's all the other session state thats being held for the connection (and the user attached to it), but this is unrelated to framing.
So a XMPP server implementation is no better or worse performance-wise than any other type of network server. Its constructed using the same principles, and suffers the same issues.
Slashdot Mirror
You're looking at three main bits to get the whole thing up and running:
(obviously there's some overlap here)
If you have limited experience with these things, a kit from somewhere like Lego or Fischertechnik is an excellent place to start. These will take care of the hard stuff, letting you get straight in. Its also a good way to test the waters - see if you really want to get into robotics (it can become addictive and expensive very quickly).
If you want to do it yourself, I recommend these books by David Cook:
See also http://www.robotroom.com/
I tend not to get into the body building much, preferring off-the-shelf stuff. Basic Lego Technic sets have served me well, and I'm currently using Tamiya gearboxes and bases. I'm far more interested in the computer side, building small microcontroller-based computers and writing the software from scratch.
Correct. iPlanet MS (the 5.x series) used the NMS message store and IMAP/POP/HTTP servers (which, as you say, were once Cyrus IMAP), and included PMDF as the MTA (I believe iPlanet bought InnoSoft to get it).
After iPlanet split, we got NMS 6.0 and Sun ONE MS 6.0. ONE became JES, which is doing some hairy integration stuff with Sun's calendar, directory and web server (we're still on iMS 5.2 where I work, and its getting harder and harder to upgrade).
As far as I know, there's nothing of SIMS in iMS/ONE MS/JES MS (thank goodness - it was the pits).
What I'm wondering, is where is Netscape's version of the code? My interest in it is purely selfish - if I had it I could fix the issues we currently have with iMS, and I could stop implementing really awful workarounds and/or rewriting parts of the MTA to do my bidding.
Where are the other bits of software that once was Netscape Suitespot?
Netscape Calendar was not actually developed by Netscape, but was a version of CS&T's CorporateTime system. CS&T later renamed to Steltor, and is now part of Oracle, CorporateTime forming a large part of their colloboration suite.
Both Netscape and Sun got copies of everything when iPlanet split. Sun still develops and sells them, first as Sun ONE, now as Java Enterprise System. Netscape tried to keep development going for a while, but it kind of stagnated (much in the same way that the Netscape browser stopped moving after the AOL aquisition).
Redhat also got Certificate Server and Enteprise Server (the web server) as part of their deal, see http://www.redhat.com/software/rha/netscape/ for more.
So where is the other Netscape software? I'm mostly talking about Messaging Server, which is an awesome piece of software, and Collabra Server, which .. isn't. Presumably they're still kicking around in a CVS in the depths of AOL somewhere. Anybody else know anything?
I had a look at Jabber years ago, but what put me off what is now known as XMPP was that it didn't solve the problem of framing stanzas. The only way to determine the borders of a stanza, and thus when you have read enough to successfully parse it, was by parsing the content.
The bulk of the discussion we had about framing Thes links constitute the bulk of the discussion we had about framing a couple of years ago:
http://mail.jabber.org/pipermail/standards-jig/200 2-January/000201.html 0 2-February/000215.html
http://mail.jabber.org/pipermail/standards-jig/20
A good summary of the discussion is here:
http://mail.jabber.org/pipermail/standards-jig/20Basically, the simple framing we were considering (for backwards-compatibility reasons) might have made implementations easier under certain circumstances but also introduced issues (misframing).
How would you go about designing a multiplexing implementation that can handle, say, 1000 connections on a 800Mhz P3 without burning a lot of CPU?
As it stands, its quite straightforward to design a high-performance Jabber server that can handle many connections. Several folks (including myself) have done it.
Most implementations use an off-the-shelf callback-based XML parser (eg Expat or a SAX-based parser). When you get a read event on a connection, you read as much is there, and feed it into the parser. The parser fires callbacks, and you process the data contained in the XML. This all runs out of a normal descriptor readiness loop (select(), poll(), that sort of thing).
CPU time is kept as minimal is possible. We are parsing XML, so its always going to take a little more effort than a binary protocol (though modern parsers are pretty efficient, and there's ways to improve it if we're willing to write a custom parser that binds tightly to the network layer - zero-copy tricks, etc).
On the memory side, Expat in particular is pretty efficient - once its finished with an element, it gets cleaned up. So while its idling, the only state its holding is the top element and its namespaces.
Obviously, there's all the other session state thats being held for the connection (and the user attached to it), but this is unrelated to framing.
So a XMPP server implementation is no better or worse performance-wise than any other type of network server. Its constructed using the same principles, and suffers the same issues.