It's sad to see that the End-to-End Encryption spec which made it in uses S/MIME.
Pretty much nobody in the community has expressed interest in implementing S/MIME-based encryption in clients, partially because the existing OpenPGP-based implementations work, but also because S/MIME is a dog to deal with, both as a developer, and as a user.
So no. I don't think you'll see any clients supporting it for quite some time. But Psi and Gabber still support OpenPGP, right?
It's interesting that you should bring up IRC. IRC has no means for determining the content length of a message without "parsing" it to wait for the newline. But parsing is grossly inefficient, apparently, so obviously it can't attain the sort of throughputs of which you speak.:-)
The XMPP spec everyone has now read describes a method for mapping XMPP over TCP. It also says that TCP is only one example of a transport for the protocol. A further JEP, JEP-0124, describes binding XMPP to HTTP... thereby HTTP becomes the transport for XMPP.
Of course, they could then invent XMPP over UDP, with one stanza (or frame) per UDP packet. Since UDP already tells you how big the frame is, your requirements are satisfied. But in all honesty, you'd have to layer the reliability stuff on top of UDP to make it usable in any real applications.:-)
Also, even in the case of the TCP binding, you don't really have to write a parser if you start with an existing parser which doesn't provide full functionality. XPP2 is an example of this kind of parser, where you can incrementally chew through and ignore tokens until you hit something you care about. All you would keep a counter for "depth", and accumulate the raw text until you hit depth 1. During the processing, you could take note of anything you care about (e.g. if you are a server, you primarily care about the attributes on the stanza itself, which say who the message has to go to.)
Since I've done this before, it can't be too hard. Harder than should be necessary, perhaps, but it isn't rocket science, either. And no, I didn't need to write my own parser, so I didn't have to worry about violating the XML spec in any way.:-)
There have always been rumours and speculations that someone like Google would get into the instant messaging space. I suppose people think of this as retaliation... Microsoft tried to infringe on the search space, which Google is pretty much the king of right now. So to get back, they really should make an instant messenger which everyone wants to use, just like they made a web mail service which it seems everyone wants to use.
If they ran such an IM system on XMPP, you would see quite a few new users accumulate in a rapid fashion, even if they didn't know they were using the protocol. Think web messenger.:-)
The other thing people are always forgetting about XMPP is that it's not just an IM protocol. If someone devises a killer app for it which isn't IM, then we might find everyone using XMPP whether they know it or not.:-)
As far as I understand it, both standards are attempting to map themselves to CPIM (RFC-3862). And I'm pretty sure there is already at least one working gateway from Jabber to SIMPLE, so the two can co-exist in practice anyway.
In the end I hope it's the developers who get the say over which one stays and which one goes. If they get intimidated by the ironic nature of SIMPLE (it's not simple!), and every developer decides to use Jabber/XMPP instead, then all the best apps should inevitably be based on Jabber. That would pull in the most users, and they would win.
About the worst thing that could happen would be for Microsoft to back SIMPLE, write some shitty apps for it, and force them down the throats of the users of their OS. Which... is probably what's going to happen, since Microsoft have been supporting SIP for some time now.
With all the news on the GeForce 6600GT lately, I would have hoped that they showed its placing in the benchmarks here... particularly since I've had my eyes on buying this card ever since Slashdot mentioned it.
You're missing a couple of points with regards to that hack:
1) (And the most obvious problem with the hack!) Not every user on a computer has Administrator privileges in order to write into the Windows system directory, where javaw resides... or even permission to write into the JDK directories. That is to say, some people work in (gasp!) offices, instead of posting naked on Slashdot as ACs from their homes.
2) If you want to bundle SWT into your application, then your users need to be informed about this hack in order for your application to look modern. Do you really think that directing ordinary users to a Wikipedia entry and telling them to do it themselves is the appropriate course of action?
Meanwhile, WX4J works natively, out of the box, with no such hacks. Why is it so hard for SWT to work the same way? Perhaps they just don't care, perhaps they are just too retarded to figure it out. I don't know.
What is interesting though, is that if you are using a Windows XP theme, then Java will pick up those changes "on the fly." And the new version seems to have solved a lot of the smaller theme issues (missing graphics on drop-downs and combo box backgrounds, strange empty borders when using a theme other than Luna, etc.) So I'm pretty chuffed, as one of the people who uses a theme other than shitty Luna.:-)
Oh, I'm sorry. I thought we were talking about Java.
In Java, you have the add(Object) method on the List interface. You need to get an int in. int is not an object. Time to box it. Either do it manually, or automatically, I don't care. Personally I would prefer automatically.
Remember that the first requirement for 1.5 was that the existing bytecode still needed to work on the new VM. If they made List support the ML style of generics, they would have needed to break the VM pretty significantly. I'm not saying they shouldn't have, though... because it would be nice to be able to use List<int> instead of List<Integer>, sure, but like I said, since the majority of collections in REAL LIFE are not of primitive types, who really gives a fuck?
Yeah, I hate the Java licensing too. It would be great if GCJ and GNU Classpath would catch up to the point where 95% of Java apps would run on them... then people could just stop using Sun's implementation on Linux, right?
A solution like 0install would be the trick for the redistribution problem, though. Nobody would redistribute Java because it would come down from Sun's site as soon as someone needed to run it.;-)
And not only was it faster to write in the first place, but the chances are your app will run on Windows out of the box without having to add arbitrary WinSock calls around the place. And it will run on BSD without adding extra network headers and libraries to the makefile after discovering half of them are missing from the default. And it will run on OSX without any knowledge of that platform at all. WORA is indeed real until people try to break it with specifically crafted examples.:-)
I don't think it will be easy to get a big momentum behind SWT, which on Windows still has the Windows 2000 look and feel... especially when Swing has the far more modern, Windows XP look and feel.
In addition to this, SWT's GTK implementation is dog slow compared to Swing on Linux.
Something like WX4J might have potential, if we get a wxQt implementation to go with wxGTK. And WX4J does look native on Windows, unlike SWT.
I know, it's pretty ironic, especially when Java had Generics before C# did, and it just got accused of copying that one off C#. If they did, then an open question to Sun is in order: can I borrow your time machine? I want to go and pick up some horse racing results from the future.
I assume you mean generics, since Java doesn't have templates. "Template" implies that extra classes are generated, but "generics" simply have type parameters.
It's a bit annoying, yes, that autoboxing is required to use primitives with collections, but that was going to be a problem irrespective of whether generics were implemented at all.
I guess we're just lucky that the majority of collections in the real world are NOT of primitive types.
Slashdot Mirror
It's sad to see that the End-to-End Encryption spec which made it in uses S/MIME.
Pretty much nobody in the community has expressed interest in implementing S/MIME-based encryption in clients, partially because the existing OpenPGP-based implementations work, but also because S/MIME is a dog to deal with, both as a developer, and as a user.
So no. I don't think you'll see any clients supporting it for quite some time. But Psi and Gabber still support OpenPGP, right?
It's interesting that you should bring up IRC. IRC has no means for determining the content length of a message without "parsing" it to wait for the newline. But parsing is grossly inefficient, apparently, so obviously it can't attain the sort of throughputs of which you speak. :-)
Maybe you replied to the wrong message. :-)
There are probably a few things to say.
The XMPP spec everyone has now read describes a method for mapping XMPP over TCP. It also says that TCP is only one example of a transport for the protocol. A further JEP, JEP-0124, describes binding XMPP to HTTP... thereby HTTP becomes the transport for XMPP.
Of course, they could then invent XMPP over UDP, with one stanza (or frame) per UDP packet. Since UDP already tells you how big the frame is, your requirements are satisfied. But in all honesty, you'd have to layer the reliability stuff on top of UDP to make it usable in any real applications. :-)
Also, even in the case of the TCP binding, you don't really have to write a parser if you start with an existing parser which doesn't provide full functionality. XPP2 is an example of this kind of parser, where you can incrementally chew through and ignore tokens until you hit something you care about. All you would keep a counter for "depth", and accumulate the raw text until you hit depth 1. During the processing, you could take note of anything you care about (e.g. if you are a server, you primarily care about the attributes on the stanza itself, which say who the message has to go to.)
Since I've done this before, it can't be too hard. Harder than should be necessary, perhaps, but it isn't rocket science, either. And no, I didn't need to write my own parser, so I didn't have to worry about violating the XML spec in any way. :-)
From that philosphy, Google does not do email either. Oh, wait a second...
Hopefully this means it's better thought out than some of the previous efforts. Half joking, and half not. ;-)
There have always been rumours and speculations that someone like Google would get into the instant messaging space. I suppose people think of this as retaliation... Microsoft tried to infringe on the search space, which Google is pretty much the king of right now. So to get back, they really should make an instant messenger which everyone wants to use, just like they made a web mail service which it seems everyone wants to use.
If they ran such an IM system on XMPP, you would see quite a few new users accumulate in a rapid fashion, even if they didn't know they were using the protocol. Think web messenger. :-)
The other thing people are always forgetting about XMPP is that it's not just an IM protocol. If someone devises a killer app for it which isn't IM, then we might find everyone using XMPP whether they know it or not. :-)
As far as I understand it, both standards are attempting to map themselves to CPIM (RFC-3862). And I'm pretty sure there is already at least one working gateway from Jabber to SIMPLE, so the two can co-exist in practice anyway.
In the end I hope it's the developers who get the say over which one stays and which one goes. If they get intimidated by the ironic nature of SIMPLE (it's not simple!), and every developer decides to use Jabber/XMPP instead, then all the best apps should inevitably be based on Jabber. That would pull in the most users, and they would win.
About the worst thing that could happen would be for Microsoft to back SIMPLE, write some shitty apps for it, and force them down the throats of the users of their OS. Which... is probably what's going to happen, since Microsoft have been supporting SIP for some time now.
With all the news on the GeForce 6600GT lately, I would have hoped that they showed its placing in the benchmarks here... particularly since I've had my eyes on buying this card ever since Slashdot mentioned it.
What a rip-off.
$90M in the past and $1B today. My, how inflation hurts. :-)
I didn't say ALL collections in the real world, I said the MAJORITY of collections in the real world.
For each and every math-related edge case like OpenGL, there are a hundred business cases where the collection is of objects.
You're missing a couple of points with regards to that hack:
1) (And the most obvious problem with the hack!) Not every user on a computer has Administrator privileges in order to write into the Windows system directory, where javaw resides... or even permission to write into the JDK directories. That is to say, some people work in (gasp!) offices, instead of posting naked on Slashdot as ACs from their homes.
2) If you want to bundle SWT into your application, then your users need to be informed about this hack in order for your application to look modern. Do you really think that directing ordinary users to a Wikipedia entry and telling them to do it themselves is the appropriate course of action?
Meanwhile, WX4J works natively, out of the box, with no such hacks. Why is it so hard for SWT to work the same way? Perhaps they just don't care, perhaps they are just too retarded to figure it out. I don't know.
Yeah, that is a bit of a problem, I'll admit.
What is interesting though, is that if you are using a Windows XP theme, then Java will pick up those changes "on the fly." And the new version seems to have solved a lot of the smaller theme issues (missing graphics on drop-downs and combo box backgrounds, strange empty borders when using a theme other than Luna, etc.) So I'm pretty chuffed, as one of the people who uses a theme other than shitty Luna. :-)
If there were a java.lang.NullPointerException, my code would have caught the exception. You can't catch segmentation faults.
Oh, I'm sorry. I thought we were talking about Java.
In Java, you have the add(Object) method on the List interface. You need to get an int in. int is not an object. Time to box it. Either do it manually, or automatically, I don't care. Personally I would prefer automatically.
Remember that the first requirement for 1.5 was that the existing bytecode still needed to work on the new VM. If they made List support the ML style of generics, they would have needed to break the VM pretty significantly. I'm not saying they shouldn't have, though... because it would be nice to be able to use List<int> instead of List<Integer>, sure, but like I said, since the majority of collections in REAL LIFE are not of primitive types, who really gives a fuck?
Yeah, I hate the Java licensing too. It would be great if GCJ and GNU Classpath would catch up to the point where 95% of Java apps would run on them... then people could just stop using Sun's implementation on Linux, right?
A solution like 0install would be the trick for the redistribution problem, though. Nobody would redistribute Java because it would come down from Sun's site as soon as someone needed to run it. ;-)
And not only was it faster to write in the first place, but the chances are your app will run on Windows out of the box without having to add arbitrary WinSock calls around the place. And it will run on BSD without adding extra network headers and libraries to the makefile after discovering half of them are missing from the default. And it will run on OSX without any knowledge of that platform at all. WORA is indeed real until people try to break it with specifically crafted examples. :-)
I don't think it will be easy to get a big momentum behind SWT, which on Windows still has the Windows 2000 look and feel... especially when Swing has the far more modern, Windows XP look and feel.
In addition to this, SWT's GTK implementation is dog slow compared to Swing on Linux.
Something like WX4J might have potential, if we get a wxQt implementation to go with wxGTK. And WX4J does look native on Windows, unlike SWT.
I know, it's pretty ironic, especially when Java had Generics before C# did, and it just got accused of copying that one off C#. If they did, then an open question to Sun is in order: can I borrow your time machine? I want to go and pick up some horse racing results from the future.
LOL. Of course I meant 5.0 in all those places where I wrote 1.5. This just goes to show how retarded this numbering scheme is making everyone.
It was the version strings which still bloody said 1.5... at least in the release candidate. I hope they fixed that since.
Not that this will really clear anything up, but...
The downloadable stuff is JDK 1.5 and JRE 1.5. They stand for "Java2 Development Kit" and "Java2 Runtime Environment" respectively.
So I would think that the colloquial name for it should be "Java2 1.5". :-/
Bah, everything can be written in C or C++. I wrote my Slashdot commenting bot in C++ and haven't seen a pro Segmentation fault (core dumped)
I assume you mean generics, since Java doesn't have templates. "Template" implies that extra classes are generated, but "generics" simply have type parameters.
It's a bit annoying, yes, that autoboxing is required to use primitives with collections, but that was going to be a problem irrespective of whether generics were implemented at all.
I guess we're just lucky that the majority of collections in the real world are NOT of primitive types.
Java announced Generics before C# did, so if it does get closer to C#, we know that it's not Java doing the walking.