I wouldn't say "most" IM clients support inline images. It's definitely a minority once you consider the myriad of clients which don't support them... there are a great deal more of these minimal clients than the full-featured clones of MSN and Co. So in theory? yes. And in practice? Also yes.
I dunno. That depends on Microsoft adopting any part of the new standard. XHTML came out years ago, and Microsoft don't even support it yet. I think it would be a long way from them supporting any SVG at all, even an incorrect implementation.
Wait, was this a joke? The TABLE element held web design back for years, and even after CSS showed up, people continued to misuse TABLE as a design element. For examples, see... this web site.
About 40% of my contacts aren't on Jabber yet, but that doesn't seem to stop me talking to them via the Jabber protocol. Hell, I can chat on IRC servers via the Jabber protocol. Why would anyone need to use the native ones anymore?:-)
Now you're talking about specific clients. Remember, IRC is an IM system itself. In theory, someone could put images in the stream over IRC, if they figured out some kind of magic codes for it. Just like they do formatting of text, when strictly IM is plaintext.
In case you missed the article, this article is about a corporate IM service, not MSN Messenger.
In other words, they saw the risks in using public IM, decided they would buy a corporate IM system, and then made an extremely poor decision by buying Microsoft's corporate IM service.
And why was it a poor decision? Because it uses the same insecure client which people use on the public IM service.:-)
So how good is the encryption? Does it actually allow me to verify that the person I'm talking to is the right person? Or is it like all the other useless encryption in the world which doesn't?
Technically (according to AOL themselves), people who have AOL use "AOLIM", not AIM. They also distinguish the two when they give out usage statistics, just like they distinguish ICQ even though they run that too.
Nobody said it isn't profitable. The original sarcasm was that there aren't many AOL users around, and that much appears to be true, at least globally.
But logging at the start and end of methods is completely useless. I want logging in the middle, with information other than what method is being called... basically it should provide what the existing logging provides, otherwise it hasn't solved anything.
My objection is that these things can both be done using a Decorator pattern, and the Decorator pattern doesn't make your code so hard to debug when errors do occur.
I wonder how many platforms said licence would run on. Even if open source developers managed to get a licence, what are the odds that it will actually run on their choice of platform? (I'd say something like 100 to 1 against.)
Slashdot Mirror
I wouldn't say "most" IM clients support inline images. It's definitely a minority once you consider the myriad of clients which don't support them... there are a great deal more of these minimal clients than the full-featured clones of MSN and Co. So in theory? yes. And in practice? Also yes.
I dunno. That depends on Microsoft adopting any part of the new standard. XHTML came out years ago, and Microsoft don't even support it yet. I think it would be a long way from them supporting any SVG at all, even an incorrect implementation.
Wait, was this a joke? The TABLE element held web design back for years, and even after CSS showed up, people continued to misuse TABLE as a design element. For examples, see... this web site.
About 40% of my contacts aren't on Jabber yet, but that doesn't seem to stop me talking to them via the Jabber protocol. Hell, I can chat on IRC servers via the Jabber protocol. Why would anyone need to use the native ones anymore? :-)
Try using a client which has the features instead of whining about features which already exist.
I bet if they fixed their client, it would have worked too. :-/
Now you're talking about specific clients. Remember, IRC is an IM system itself. In theory, someone could put images in the stream over IRC, if they figured out some kind of magic codes for it. Just like they do formatting of text, when strictly IM is plaintext.
In case you missed the article, this article is about a corporate IM service, not MSN Messenger.
In other words, they saw the risks in using public IM, decided they would buy a corporate IM system, and then made an extremely poor decision by buying Microsoft's corporate IM service.
And why was it a poor decision? Because it uses the same insecure client which people use on the public IM service. :-)
So how good is the encryption? Does it actually allow me to verify that the person I'm talking to is the right person? Or is it like all the other useless encryption in the world which doesn't?
Wow, two pairs of husband and wife? Amazing.
It probably would have made more sense to only give the feature to administrators. :-/
But then 5000 would be missing!
Technically (according to AOL themselves), people who have AOL use "AOLIM", not AIM. They also distinguish the two when they give out usage statistics, just like they distinguish ICQ even though they run that too.
Nobody said it isn't profitable. The original sarcasm was that there aren't many AOL users around, and that much appears to be true, at least globally.
Perhaps it is you who needs to get their head out of their . . .
Not really.
We have AOL here too (Australia), but I don't know of a single real person who actually uses it.
Yeah, I hear it even connects to multiple IM services, and will be open source.
There really aren't very many of those people around. Well, unless you have your head stuck firmly in US soil.
Such a shame, too... I was hoping they might just implement XMPP. ;-)
Not to mention the episode guides, which have listed episode 6 as being Dalek since before the first episode ever aired!
I don't like coding on the morning of a public holiday, but here's how it worked in the days before people discovered exceptions.
But as others have said, exceptions are much, much better. Except, of course, C++ exceptions, which suck.
But logging at the start and end of methods is completely useless. I want logging in the middle, with information other than what method is being called... basically it should provide what the existing logging provides, otherwise it hasn't solved anything.
My objection is that these things can both be done using a Decorator pattern, and the Decorator pattern doesn't make your code so hard to debug when errors do occur.
But what does AOP solve in that logging scenario? As far as I can tell, it lets you change this:
Into this:
Four less characters, whoop-di-shit.
And that's not even going into the fact that static import brings exactly the same benefit.
Well done, you can do the exact same thing without goto by merely inverting the if-condition.
I wonder how many platforms said licence would run on. Even if open source developers managed to get a licence, what are the odds that it will actually run on their choice of platform? (I'd say something like 100 to 1 against.)