The XMPP server we provide from Jabber, Inc. provides the ability to log all messages that come in to and go out of the server. It is imperative that all traffic be logged at the server; some IM systems try to do without this by having the client send an extra copy of peer-to-peer messages off to a compliance server, but there are lots of ways that second connection could be defeated.
Typically in a corporate environment, clients will connect using SSL or TLS, so the wire traffic is encrypted, but the messages themselves are plaintext for easy of retrieval from the archive solution. It is possible to do end-to-end encryption, but in these environments you would need a key escrow solution, which is more trouble that people seem to want at this point.
Now use it in a sentance.:) If this is an inner class in class foo, then in order to use it as a parameter to a method, I need to do: aFoo.bar(foo.Animal.PIG); Which seems like a mouthful, particularly since enums have been around at least since Pascal, and they solve the problem very neatly. Just because you can make the Animal.PIG dance, doesn't mean it's art.
I've been touting Java as a good language for doing software engineering, particularly for larger systems. Java is hampered in a couple of ways for this purpose, but the most glaring is the lack of enums. It would be cool to have cool syntax for properties, rather than using a naming standard (getX(), setX()), and it would be cool if there was a more standardized way of doing events. We can argue about whether operator overloading is a good thing, but I've finally convinced myself that multiple inheritance of implementation isn't a good thing (no more mixins).
It looks like C# fixes several of these (enums, properties, events, operator overloading), but leaves out some of the best features that Java includes:
Including thrown exceptions in a method's type signature, so that the compiler can check exception usage. This is essential to ensure that programmers down the line are given the chance to do correct error handling. I worked on a big project in Ada, and we were never quite sure (without looking at the source for the callee) what exceptions were going to be thrown. Since the C# Language Reference's section on exception is left blank, I suppose this may get fixed before release.
Out-of-the-box literate programming. Javadoc may not be perfect, but it sure is better than writing the programmer-level documentation by hand. Keeping the documentation of a class next to the interface is a huge win. Yes, it looks like you could cobble something together with attributes, but I'd much rather that the language set the standard, so that development tools can be written that capitalize on the feature. Plus, the syntax for declaring attributes is a little precious and overly IDL-like.
Destructors are going to be really confusing for C++ programmers. They are going to expect that the destructors get called at predictable times, instead of at garbage-collection time. In the first implementation of the compiler, they might even be right. When the lazy garbage collector is added in, though, the similarities to Java finalizers will bite people who wait to close files until the destructor.
The return of "virtual". I'm willing to pay one more memory look-up every time I call a method, already. Just make all functions virtual, and don't confuse the newbies who expect this behavior.
No anonymous classes. These are a lot less needed in C#, due to delegates, but they're just so handy. This isn't really a software engineering issue, aside from the fact that in some projects, there is a large amount of overhead in creating a new class.
It's unclear if you'll be able to call the Windows API directly. I'd like to not have write an import statement every time I go outside the box.
Even though it looks like they are going for ECMA standardization, I'll wait until I see a version of this running on a non-MS, non-Intel platform before I can use it seriously for large, enterprise class solutions. In these environments, there are always other platforms involved, and I'd like to be able to use a single language.
UI? The best would be to just write a package that interfaces with Tk.
What else is good about C#:
All types, including built-ins, automatically coerce to subclasses of object. No more overloading for all of the different types that can be passed in.
Versioning. We'll see if it actually works.
Potentially built-in COM access. If you've tried to do this in C++ (particularly without ATL), you know how hard this can be. It is implied in the Interoperability section that this won't be quite so hard. You could certainly write a wizard that, given the progid of a COM object, would generate all of the COMImport attributes automatically from the COM object's type library.
It's implied that C# compiles down to a real executable. I don't care if I have to recompile for different OS/hardware combinations, as long as I can distribute the binary as a stand-alone. That's one thing that is holding Java back. I have to assume that users have the JRE, in order to get them a reasonably-sized program.
John Barnes' new book Finity discusses the potential downsides of the quantum interface in some depth. The book is basically a quantum look at Heinlein's idea for The Number of the Beast, without being as well executed.
The question is, how does observing the answer to a question posed to a quantum computing device change the questioner? If you are a subscriber to the many-worlds inperpretation (MWI), you might surmise that one questioner is created for each possible outcome. Imagine there being two Schrodingers, one for each cat.
I suppose the nice thing about science fiction that is based on the MWI is that it tends to be logically consistent about time travel, while remaining interesting. An example of a fiction that isn't logically consistent: 7 days. One where non-paradoxical time travel leads to fatalism: White Dragon, by Anne McCaffrey. Simon Hawke's Time Wars series, while not being wonderfully written, are at least logically consistent, due to their reliance on the MWI.
It's probably too late in this thread to be of use, but RFC 1178 has a good discussion of this exact problem. It often helps in this discussion as an appeal-to-authority argument, which works better on PHBs than technical folks.
On other operating systems, any local addresses are usually routed to the loopback interface, in the same way that 127.0.0.0/8 is. It may actually do so in the Linux kernel, due to the "H" in the flags column...
A quick look at net/ipv4/route.c makes me believe that something of the sort is going on.
The important part of the diagram is that there is only a source IP address and a destination IP address on each packet, but no subnet mask.
One big reason for the subnet mask is routing. Let's pretend we're the routing code in the IP stack. A packet is handed to us, and we look at the destination address. We compare that destination with our routing table, looking for the closest match. For example, if the routing table looks like (edited for something like clarity):
$ netstat -nr Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo 192.168.1.2 0.0.0.0 255.255.255.255 UH 0 0 0 eth0 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 eth0
Consider a packet with the address 127.0.0.1. We bitwise "and" it with the network mask from the first route (255.0.0.0), and get 127.0.0.0. This is a match, so we send the packet to the loopback interface, "lo", which in all probability won't cause any traffic on the wire connected to my box.
For 192.168.1.50, we'd go down the list, looking for a match, until we got to the third rule. Applying the network mask, we get 192.168.1.0, which matches the destination for this route. We'll send the packet to the ethernet address, and do an ARP to resolve it's ethernet address, which we need to send a packet on the local network.
Note that the last line, 0.0.0.0 (mask 0.0.0.0), matches everything. This is the default route. The IP address you see here is the router that we want to make the next hop routing decision for us.
For those that want to know more about private network numbers, see RFC 1918.
Re:A few lessons learned (ADSL in Denver [U.S. Wes
on
Feature: Getting DSL
·
· Score: 1
I'd recommend against using US West as your ISP. Although you would like to think that having a single point of contact would minimize the amount of finger-pointing, my experience shows that this is not the case. There are ISP people, and phone people, and none of them seem to know which end is up. After 3 months, I *finally* got my ISP switched, and now everything seems to work. As always, whenever you talk to someone at US West, log the date, time, the person's name, and ask them for a direct number where you can call them back. If you find a "customer service" rep that is actually helpful, hold on to the number. Beware of the "Certainly, we'll get to that as soon as possible. We're sorry for the delay. Click. Silence." syndrome.
Slashdot Mirror
http://xmpp.org/drafts/draft-saintandre-atompub-no tify-01.html
The XMPP server we provide from Jabber, Inc. provides the ability to log all messages that come in to and go out of the server. It is imperative that all traffic be logged at the server; some IM systems try to do without this by having the client send an extra copy of peer-to-peer messages off to a compliance server, but there are lots of ways that second connection could be defeated.
Typically in a corporate environment, clients will connect using SSL or TLS, so the wire traffic is encrypted, but the messages themselves are plaintext for easy of retrieval from the archive solution. It is possible to do end-to-end encryption, but in these environments you would need a key escrow solution, which is more trouble that people seem to want at this point.
Ever try to migrate an installed base from 1.1 to 1.2? Yeah, it's not DLL hell, but it's not as simple as just sending out a new .jar file.
Now use it in a sentance. :) If this is an inner class in class foo, then in order to use it as a parameter to a method, I need to do: aFoo.bar(foo.Animal.PIG); Which seems like a mouthful, particularly since enums have been around at least since Pascal, and they solve the problem very neatly. Just because you can make the Animal.PIG dance, doesn't mean it's art.
It looks like C# fixes several of these (enums, properties, events, operator overloading), but leaves out some of the best features that Java includes:
What else is good about C#:
The question is, how does observing the answer to a question posed to a quantum computing device change the questioner? If you are a subscriber to the many-worlds inperpretation (MWI), you might surmise that one questioner is created for each possible outcome. Imagine there being two Schrodingers, one for each cat.
I suppose the nice thing about science fiction that is based on the MWI is that it tends to be logically consistent about time travel, while remaining interesting. An example of a fiction that isn't logically consistent: 7 days. One where non-paradoxical time travel leads to fatalism: White Dragon, by Anne McCaffrey. Simon Hawke's Time Wars series, while not being wonderfully written, are at least logically consistent, due to their reliance on the MWI.
It's probably too late in this thread to be of use, but RFC 1178 has a good discussion of this exact problem. It often helps in this discussion as an appeal-to-authority argument, which works better on PHBs than technical folks.
On other operating systems, any local addresses are usually routed to the loopback interface, in the same way that 127.0.0.0/8 is. It may actually do so in the Linux kernel, due to the "H" in the flags column...
A quick look at net/ipv4/route.c makes me believe that something of the sort is going on.
One big reason for the subnet mask is routing. Let's pretend we're the routing code in the IP stack. A packet is handed to us, and we look at the destination address. We compare that destination with our routing table, looking for the closest match. For example, if the routing table looks like (edited for something like clarity):
Consider a packet with the address 127.0.0.1. We bitwise "and" it with the network mask from the first route (255.0.0.0), and get 127.0.0.0. This is a match, so we send the packet to the loopback interface, "lo", which in all probability won't cause any traffic on the wire connected to my box.
For 192.168.1.50, we'd go down the list, looking for a match, until we got to the third rule. Applying the network mask, we get 192.168.1.0, which matches the destination for this route. We'll send the packet to the ethernet address, and do an ARP to resolve it's ethernet address, which we need to send a packet on the local network.
Note that the last line, 0.0.0.0 (mask 0.0.0.0), matches everything. This is the default route. The IP address you see here is the router that we want to make the next hop routing decision for us.
For those that want to know more about private network numbers, see RFC 1918.
I'd recommend against using US West as your ISP. Although you would like to think that having a single point of contact would minimize the amount of finger-pointing, my experience shows that this is not the case. There are ISP people, and phone people, and none of them seem to know which end is up. After 3 months, I *finally* got my ISP switched, and now everything seems to work. As always, whenever you talk to someone at US West, log the date, time, the person's name, and ask them for a direct number where you can call them back. If you find a "customer service" rep that is actually helpful, hold on to the number. Beware of the "Certainly, we'll get to that as soon as possible. We're sorry for the delay. Click. Silence." syndrome.