I'm a software developer. I've been programming for years. I started it as a hobby, took all the relevant courses at school and eventually took it on as a profession. I enjoy programming, but I only enjoy it when I'm calling the shots. It's not fun when you're just writing something that someone else wants you to write. The things I want to write are fun and interesting but not profitable. The things other people want me to write are profitable but dull and boring.
They say the test of whether you've found the right career is whether you'd do it even if no-one paid you. I'd actually prefer it if I didn't have to do it as a job, since it'd be a lot more fun.
The problem with the approach you're describing is that a company that doesn't take part ends up better off. Company A and Company B both invest 100k into OpenOffice and get out of it a useful office product. Company C, which has the same requirements as Company A, also gains a free office product without having to invest that 100k. Company C has come out on top.
Of course, if no companies do it then no-one benefits, but which company is going to be the one that makes the sacrifice for the good of everyone else? Not my company, that's for sure.
It seems to me that what should be done is to make the devices "stand by" more efficiently. A CRT television on standby isn't just keeping the circuits alive to react to the remote, it's powering part of the tube so that it will produce a picture faster when it's turned on. I wonder how much power would be saved if standby mode was to turn off the set completely and just keep the remote sensor active.
In the more general case, research should be conducted to find ways to make these devices more efficient so that when they are in standby mode they do essentially nothing. Hopefully such research would make for products that are more efficient when they are working too, which can only be a good thing. Such research might also prove useful for mobile devices running from batteries.
Throughout my CS degree (which I completed in 2002) we had exams that required Java programs to be written out on an exam paper in pen.The first time you do it you can find it a rude awakening just how much you've come to depend on API docs, but in reality the markers are generally marking your algorithm or approach rather than your knowledge of the API and syntax, so they forgive minor errors such as writting toLower() instead of toLowerCase() or whatever. They would even give partial credit for pseudo-code that was detailed enough to show understanding.
Personally, after the initial shock of the first one I quite enjoyed the others. As much as you can enjoy an exam, anyway. It was an interesting challenge to be under time constraints and be relying only on your own knowledge.
AJAX with XUL in Mozilla
on
Web 3.0
·
· Score: 3, Informative
It should be noted that it's possible to use AJAX with XUL in Mozilla. XUL gives you a UI toolkit based around a DOM, and while it has its shortcomings it's definitely a lot better than HTML. Since XUL is XML-based the same techniques used to deal with AJAX in HTML can be applied, but you also get XBL bindings which allow you to hide bundles of functionality behind opaque objects thus creating custom widgets. Also, both the builtin widgest and any custom ones can be styled using CSS so you can still get your brand in there.
Of course, it only works in Mozilla-based browsers. Not much good on the Internet right now, but at my company we have a few internal webapps based on the Mozilla "platform" which seem to work well for the users. I think this is a good place to head: all that's lacking is a good standard which serves the same purpose as XUL. XUL itself is adequate, but there are a few places where I think it needs a bit of work before it can be considered good enough for widespread development. XBL is already good, and for Mozilla browsers it can already be applied to HTML and SVG documents so it's by no means XUL-specific.
Microsoft seems to be heading in a similar direction with XAML. I think it'd be a good idea to get a good, general, open standard out there before Microsoft launches XAML and it's too late.
Let's pretend for a moment that we're talking about WWE Wrestling. In WWE Wrestling, the combat is performed by actors and the result is fixed from the start. The production company decides how the fight will pan out and who will win, with the hope that the fight and outcome will be interesting enough to attract viewers. The progression and outcome of the match is therefore a creative work, funded by and created by the TV company. You could argue that the match outcome is as protected by copyright as the set and costume designs, theme tune and so forth.
If we apply the situation to actual sports such as baseball, the only difference is that the outcome is decided (to a certain extent) by the players. The players put in effort to practice and train to become good at their sport. The players are paid for their "performance", so any creative work they produce while on the job is work for hire and thus owned by the company. The outcome of the match is a derivative work resulting from the skill of the players, which is itself owned by the company. Therefore the outcome is owned by the company.
I guess that's roughly how the thinking goes, anyway. I can't say that I completely agree with it, but there you are: there is something resembling a logical explanation.
Throughout my last few years of high school I was regularly getting five to six hours sleep per night due to spending the wee hours hacking away on my favorite open source projects. During the day at school I was irritable, unable to concentrate and I nearly flunked my exams as a result. Fortunately, I got a figurative kick up the ass just in time and got my act together, focused on my studies and actually impressed myself at how well I can perform with a sensible amount of sleep.
You might think you're being more productive by shaving off a few hours sleep per night, but you will most likely find that your increased concentration as a result of having a natural amount of sleep will make your work time more fruitful despite it being shorter.
Round-half-even thing was, if I recall correctly (it's been a while), the standard algorithm used when converting a float to an integer in Visual Basic. It was one of those things that got newbies quite confused at first, since they were either used to floor()-type rounding from working in other languages or the round-half-up they learned at school.
IE has a few different MIME types for which it enables the magic. text/plain, application/octet-stream and text/html all enable this magic, because traditionally web servers have determined content type by file extension and have defaulted to one of these types when they don't have an entry for the file extension given.
This was a practical problem during PNG's infancy, when Apache's default configuration didn't know what the.png file extension was and just served them as text/plain. Most webmasters who deal with this kind of setup don't know anything about HTTP headers, let alone know how to fix the problem. The IE developers took the approach of implementing this fix in the client to help out such webmasters. IE has many "features" like this to avoid webmasters actually having to be good at being webmasters. In some ways it has been more of a hinderance than a help.
The Content-Disposition header field with a value of "attachment" will cause IE to ask the user to save or open the file rather than displaying it in-browser. This is generally considered to be the "right" way to solve this problem, for some value of "right".
Giving a generic MIME type means that the browser won't be able to figure out what type the file really is, so when the user does save it it'll end up with the wrong file extension/resource fork/whatever; in IE's case, it just guesses from what the file extension on the end of the URL was, which is also quite a dangerous thing to do in some circumstances.
That's almost as bad because I still have to go back and set everything up again. If I've copied an app rather than just installing it from scratch, chances are I did it because I was hoping to bring over my config changes too. I generally do this these days by just exporting a chunk of the registry, but some apps seem to do something more "clever" which causes them to break even if I do this.
There was a VoIP app I used to use (whose name escapes me) which seemed to work okay for a few minutes and then would inexplicably pop up a dialog box saying something along the lines of "Application broken. Please reinstall." I just ended up uninstalling it.
Syntactic sugar for getters and setters can be useful for providing a more natural interface (as long as people don't abuse them), but they don't really have any place in a language like C++, where almost everything is set in stone at compile time. Properties work well in dynamic languages like JavaScript because the binding takes place at runtime, at the very last moment before the member access is resolved. The code to access a plain member field vs. a property is quite different, and in C++ this must be generated at compile time.
The upshot of this is that you can't change a field to a property and vice-versa while retaining binary compatibility. This means that you've essentially added a gotcha to the language which everyone must be wary of when designing their public interfaces. While a.b = c looks a bit prettier than a.setB(c), in my opinion it's better to be explicit about what's going on to avoid problems down the line.
Since the vulnerability is apparently in GDI32.DLL, I'd guess that every version of Windows going back to Windows 95 is vulnerable, since metafiles have been around since Windows 3 (I think?) and GDI32.DLL was introduced with the 32-bit Windows API.
The WMF format is simply a stream of GDI commands. GDI (Graphics Device Interface) is the Windows API and abstraction layer for graphics, allowing the same set of drawing functions to be targetted at a variety of different "device contexts" such as printers and the screen.
A WMF file is (traditionally) created by obtaining a device context on a file and drawing to it using the GDI API functions, which "records" the sequence of commands to disk ready to be replayed later to recreate the image. These days, of course, there are libraries and applications which read and write WMF files directly, such as libwmf. There's little practical use for this format outside of Windows development, however.
There's a second format called "Enhanced Metafile" (EMF) which is a newer, 32-bit version of the WMF format introduced with the 32-bit Windows API.
I got an e-mail a few weeks ago saying it was down and they didn't know how to get it back up.
And there, I think, is the crux of why management might resist version control in the first place: support costs. It's fine as long as you're there, but now you're not they need to find someone else to support it or else the business is completely blocked. Of course, you won't get any argument from me that version control software is essential for any professional software development, but I can certainly see management's point of view. What the OP needs to do, and what you perhaps should have done, is give a proposal in terms of the financial benefit vs. the estimated loss caused by untracked faults, etc.
At my place of work we use Subversion, but most of the other staff seem incapable of using it correctly. They'll work for a week and then commit all of their changes in one go, completely defeating the object of the revision log. It's important to remember that not all developers are familiar with version control, and developers might have to adapt their workflow which may cause a productivity hit and thus additional cost in the short term.
There's no technical reason why you couldn't get a little program which polls an RSS file and sends you an email for each new item. RSS is just data: how you consume it is up to you.
Indeed. I'd go so far as to say that the metallic cylons would be far less "sinister" and scary if we saw them as a matter of course. The fact that they are often depicted as an unseen enemy behind the camera, or as merely a shadow on the wall, just adds to the thrill on the few occasions when we do actually get to see them "in the flesh" (if you'll forgive the rather inappropriate turn of phrase).
I, for one, enjoyed the whole "winding" aspect of VHS. It was nice to have something so simple that I could stop it, walk off and do something else and then come back later -- possibly on a completely different player -- and resume from exactly where I left off. It was DVD's other benefits (quality and longevity in particular) that got me to finally switch.
I run some club nights at a local venue in which we often put some silly visuals on the televisions just to give people something to ogle and perhaps create a talking point for my patrons. We experimented with all sorts of "clever" ways to present this stuff, the most interesting being a modded XBox playing video files from its hard disk with a USB bluetooth thinger plugged into one of the controller ports so that I could control it remotely.
In practice though, these fancy modern solutions are terrible in the face of failures and just give me more to worry about. I now just prepare a four-hour VHS video in long-play mode with the stuff I want to play (still using that XBox, in fact) and just use a VCR on the night. VHS is so simple that there's not much that can go wrong. If we have a technical problem with the AV equipment we can just carry on from where we left off rather than having to screw around with a DVD player or an XBox when I've got more important things to be doing. Fortunately, the quality/longevity thing isn't too important in this scenario because these things are generally just used once and then recorded over, and no-one really gets close enough to the screens to notice the quality anyway.
ISPs won't make this mandatory unless most customers can support it and it provides some benefit for them. Most customers won't buy it unless it provides them with some other benefit or unless it's somehow marketed as a "good thing" despite masses of people crying foul. This is a catch 22.
The only way this will quickly come into practice is for a government to legislate a requirement for it. This will only affect the country in which the law is changed, and it will put that country at a disadvantage globally since the rest of the world will be able to operate on cheaper hardware and software without the trust requirement.
For these reasons I think your description is an ultimate worst-case scenario, and unlikely to arise in practice. What is more likely is that the trust chips will be used for more local restrictions such as supporting DRM on media files, and will thus be completely ignorable to anyone who is willing to forego the use of media files with DRM requirements. I've managed to survive without using media files with DRM requirements so far, and I don't see that changing any time soon.
While you are right that there is no legal way to get the XBox SDK to build these homebrew apps, once they are built it's a bit of a stretch to say that it's illegal to use them. The person who built the app is infringing copyright by using the SDK without a licence, but you don't need the SDK to actually run the result.
EMail addresses and IM addresses will never be identical without some layer of abstraction, because both expose some of the mechanics of how the messages are routed. In order for my Jabber ID to be the same as my email address, I must either manage my own domain -- which isn't an option for most people at this point -- or use the same provider for my email and my Jabber services. A user can choose to set things up this way for his own email address and Jabber ID, but no-one will ever be able to make the assumption that the two will always be identical.
Now what would be useful is some kind of service (decentralised, naturally) which gives every user a single identifier which can then be used to look up a user's Jabber ID or email address (or a webblog URL, telephone number...). Could even just use DNS for this with a few new RR types. People would probably want to do it in an authenticated manner though, so that they can control the distribution of their contact details; I guess things like LID can be used for this in theory. LID uses URLs as the universal identifier. Not much use until it gains critical mass, though.
The company I work at has two arms. There's an arm which develops bespoke software solutions for businesses, and these are generally Windows-based because that's what the company is already using or what the company knows about.
The other arm makes websites for local small businesses. This arm was created mostly as a little monetary prop-up between big software projects when the company was small. About a year ago an enterprising young web developer decided it'd be easier for him if he wrote a simple CMS to manage our website. Since this was not an officially-approved project and the website was running on a Plesk server at the time, he wrote the CMS in PHP using mySQL for the database. Once the boss got wind of this he decided it would be nice to use this software for client sites so that they could update their own stuff without having to come back to us.
A year on our CMS product has come on in leaps and bounds, and it is that I spend most of my time working on. However, it's like a little island of open source in an otherwise Microsoft world. Consequently, all of the development happens on Windows servers with the Windows version of Apache usually relegated to some non-standard port because IIS is in the way on port 80. There's only one non-Windows server in the whole place and it is not allocated for development. Open source gets a rough deal in my company, and I suspect the same is true in most places.
CSS already allows for only transferring the necessary stylesheet. In your HTML document you can specify which media types a given referenced stylesheet apply to and the browser can then determine which stylesheets are relevant to it. You still need to transfer the HTML document, but there shouldn't be any extraneous crap in the HTML document if the presentation is properly confined to the stylesheets anyway. (In practice there is usually a bit of "leakage" due to limitations of CSS2, but in most cases it's just a few extra DIVs and SPANs.
In this case it was probably a sensible choice. There are phones out there that only support the XHTML mobile profile or XHTML basic, and while they'll attempt to render normal XHTML documents they don't have a "tag-soup" parser available to try to render normal HTML. All of the latest phones have browsers capable of rendering normal pages (Opera with its small screen rendering, for example) but I think Google is also catering to the previous generation where XHTML support was just hacked on top of the WML (WAP markup) support using the existing XML parser.
Google should implement server-to-server but drop any incoming messages from users that are not on the recieving user's roster. This way people can still talk to their friends on other Jabber servers but unsolicited messages won't be a problem since they'll be dropped outright.
This may cause difficulties for agents that aren't people, such as services and bots, but at least it would open things up a little for person-to-person communication.
Slashdot Mirror
I'm a software developer. I've been programming for years. I started it as a hobby, took all the relevant courses at school and eventually took it on as a profession. I enjoy programming, but I only enjoy it when I'm calling the shots. It's not fun when you're just writing something that someone else wants you to write. The things I want to write are fun and interesting but not profitable. The things other people want me to write are profitable but dull and boring.
They say the test of whether you've found the right career is whether you'd do it even if no-one paid you. I'd actually prefer it if I didn't have to do it as a job, since it'd be a lot more fun.
The problem with the approach you're describing is that a company that doesn't take part ends up better off. Company A and Company B both invest 100k into OpenOffice and get out of it a useful office product. Company C, which has the same requirements as Company A, also gains a free office product without having to invest that 100k. Company C has come out on top.
Of course, if no companies do it then no-one benefits, but which company is going to be the one that makes the sacrifice for the good of everyone else? Not my company, that's for sure.
It seems to me that what should be done is to make the devices "stand by" more efficiently. A CRT television on standby isn't just keeping the circuits alive to react to the remote, it's powering part of the tube so that it will produce a picture faster when it's turned on. I wonder how much power would be saved if standby mode was to turn off the set completely and just keep the remote sensor active.
In the more general case, research should be conducted to find ways to make these devices more efficient so that when they are in standby mode they do essentially nothing. Hopefully such research would make for products that are more efficient when they are working too, which can only be a good thing. Such research might also prove useful for mobile devices running from batteries.
Throughout my CS degree (which I completed in 2002) we had exams that required Java programs to be written out on an exam paper in pen.The first time you do it you can find it a rude awakening just how much you've come to depend on API docs, but in reality the markers are generally marking your algorithm or approach rather than your knowledge of the API and syntax, so they forgive minor errors such as writting toLower() instead of toLowerCase() or whatever. They would even give partial credit for pseudo-code that was detailed enough to show understanding.
Personally, after the initial shock of the first one I quite enjoyed the others. As much as you can enjoy an exam, anyway. It was an interesting challenge to be under time constraints and be relying only on your own knowledge.
It should be noted that it's possible to use AJAX with XUL in Mozilla. XUL gives you a UI toolkit based around a DOM, and while it has its shortcomings it's definitely a lot better than HTML. Since XUL is XML-based the same techniques used to deal with AJAX in HTML can be applied, but you also get XBL bindings which allow you to hide bundles of functionality behind opaque objects thus creating custom widgets. Also, both the builtin widgest and any custom ones can be styled using CSS so you can still get your brand in there.
Of course, it only works in Mozilla-based browsers. Not much good on the Internet right now, but at my company we have a few internal webapps based on the Mozilla "platform" which seem to work well for the users. I think this is a good place to head: all that's lacking is a good standard which serves the same purpose as XUL. XUL itself is adequate, but there are a few places where I think it needs a bit of work before it can be considered good enough for widespread development. XBL is already good, and for Mozilla browsers it can already be applied to HTML and SVG documents so it's by no means XUL-specific.
Microsoft seems to be heading in a similar direction with XAML. I think it'd be a good idea to get a good, general, open standard out there before Microsoft launches XAML and it's too late.
Let's pretend for a moment that we're talking about WWE Wrestling. In WWE Wrestling, the combat is performed by actors and the result is fixed from the start. The production company decides how the fight will pan out and who will win, with the hope that the fight and outcome will be interesting enough to attract viewers. The progression and outcome of the match is therefore a creative work, funded by and created by the TV company. You could argue that the match outcome is as protected by copyright as the set and costume designs, theme tune and so forth.
If we apply the situation to actual sports such as baseball, the only difference is that the outcome is decided (to a certain extent) by the players. The players put in effort to practice and train to become good at their sport. The players are paid for their "performance", so any creative work they produce while on the job is work for hire and thus owned by the company. The outcome of the match is a derivative work resulting from the skill of the players, which is itself owned by the company. Therefore the outcome is owned by the company.
I guess that's roughly how the thinking goes, anyway. I can't say that I completely agree with it, but there you are: there is something resembling a logical explanation.
Throughout my last few years of high school I was regularly getting five to six hours sleep per night due to spending the wee hours hacking away on my favorite open source projects. During the day at school I was irritable, unable to concentrate and I nearly flunked my exams as a result. Fortunately, I got a figurative kick up the ass just in time and got my act together, focused on my studies and actually impressed myself at how well I can perform with a sensible amount of sleep.
You might think you're being more productive by shaving off a few hours sleep per night, but you will most likely find that your increased concentration as a result of having a natural amount of sleep will make your work time more fruitful despite it being shorter.
Round-half-even thing was, if I recall correctly (it's been a while), the standard algorithm used when converting a float to an integer in Visual Basic. It was one of those things that got newbies quite confused at first, since they were either used to floor()-type rounding from working in other languages or the round-half-up they learned at school.
IE has a few different MIME types for which it enables the magic. text/plain, application/octet-stream and text/html all enable this magic, because traditionally web servers have determined content type by file extension and have defaulted to one of these types when they don't have an entry for the file extension given.
This was a practical problem during PNG's infancy, when Apache's default configuration didn't know what the .png file extension was and just served them as text/plain. Most webmasters who deal with this kind of setup don't know anything about HTTP headers, let alone know how to fix the problem. The IE developers took the approach of implementing this fix in the client to help out such webmasters. IE has many "features" like this to avoid webmasters actually having to be good at being webmasters. In some ways it has been more of a hinderance than a help.
The Content-Disposition header field with a value of "attachment" will cause IE to ask the user to save or open the file rather than displaying it in-browser. This is generally considered to be the "right" way to solve this problem, for some value of "right".
Giving a generic MIME type means that the browser won't be able to figure out what type the file really is, so when the user does save it it'll end up with the wrong file extension/resource fork/whatever; in IE's case, it just guesses from what the file extension on the end of the URL was, which is also quite a dangerous thing to do in some circumstances.
That's almost as bad because I still have to go back and set everything up again. If I've copied an app rather than just installing it from scratch, chances are I did it because I was hoping to bring over my config changes too. I generally do this these days by just exporting a chunk of the registry, but some apps seem to do something more "clever" which causes them to break even if I do this.
There was a VoIP app I used to use (whose name escapes me) which seemed to work okay for a few minutes and then would inexplicably pop up a dialog box saying something along the lines of "Application broken. Please reinstall." I just ended up uninstalling it.
Syntactic sugar for getters and setters can be useful for providing a more natural interface (as long as people don't abuse them), but they don't really have any place in a language like C++, where almost everything is set in stone at compile time. Properties work well in dynamic languages like JavaScript because the binding takes place at runtime, at the very last moment before the member access is resolved. The code to access a plain member field vs. a property is quite different, and in C++ this must be generated at compile time.
The upshot of this is that you can't change a field to a property and vice-versa while retaining binary compatibility. This means that you've essentially added a gotcha to the language which everyone must be wary of when designing their public interfaces. While a.b = c looks a bit prettier than a.setB(c), in my opinion it's better to be explicit about what's going on to avoid problems down the line.
Since the vulnerability is apparently in GDI32.DLL, I'd guess that every version of Windows going back to Windows 95 is vulnerable, since metafiles have been around since Windows 3 (I think?) and GDI32.DLL was introduced with the 32-bit Windows API.
The WMF format is simply a stream of GDI commands. GDI (Graphics Device Interface) is the Windows API and abstraction layer for graphics, allowing the same set of drawing functions to be targetted at a variety of different "device contexts" such as printers and the screen.
A WMF file is (traditionally) created by obtaining a device context on a file and drawing to it using the GDI API functions, which "records" the sequence of commands to disk ready to be replayed later to recreate the image. These days, of course, there are libraries and applications which read and write WMF files directly, such as libwmf. There's little practical use for this format outside of Windows development, however.
There's a second format called "Enhanced Metafile" (EMF) which is a newer, 32-bit version of the WMF format introduced with the 32-bit Windows API.
And there, I think, is the crux of why management might resist version control in the first place: support costs. It's fine as long as you're there, but now you're not they need to find someone else to support it or else the business is completely blocked. Of course, you won't get any argument from me that version control software is essential for any professional software development, but I can certainly see management's point of view. What the OP needs to do, and what you perhaps should have done, is give a proposal in terms of the financial benefit vs. the estimated loss caused by untracked faults, etc.
At my place of work we use Subversion, but most of the other staff seem incapable of using it correctly. They'll work for a week and then commit all of their changes in one go, completely defeating the object of the revision log. It's important to remember that not all developers are familiar with version control, and developers might have to adapt their workflow which may cause a productivity hit and thus additional cost in the short term.
There's no technical reason why you couldn't get a little program which polls an RSS file and sends you an email for each new item. RSS is just data: how you consume it is up to you.
Indeed. I'd go so far as to say that the metallic cylons would be far less "sinister" and scary if we saw them as a matter of course. The fact that they are often depicted as an unseen enemy behind the camera, or as merely a shadow on the wall, just adds to the thrill on the few occasions when we do actually get to see them "in the flesh" (if you'll forgive the rather inappropriate turn of phrase).
I, for one, enjoyed the whole "winding" aspect of VHS. It was nice to have something so simple that I could stop it, walk off and do something else and then come back later -- possibly on a completely different player -- and resume from exactly where I left off. It was DVD's other benefits (quality and longevity in particular) that got me to finally switch.
I run some club nights at a local venue in which we often put some silly visuals on the televisions just to give people something to ogle and perhaps create a talking point for my patrons. We experimented with all sorts of "clever" ways to present this stuff, the most interesting being a modded XBox playing video files from its hard disk with a USB bluetooth thinger plugged into one of the controller ports so that I could control it remotely.
In practice though, these fancy modern solutions are terrible in the face of failures and just give me more to worry about. I now just prepare a four-hour VHS video in long-play mode with the stuff I want to play (still using that XBox, in fact) and just use a VCR on the night. VHS is so simple that there's not much that can go wrong. If we have a technical problem with the AV equipment we can just carry on from where we left off rather than having to screw around with a DVD player or an XBox when I've got more important things to be doing. Fortunately, the quality/longevity thing isn't too important in this scenario because these things are generally just used once and then recorded over, and no-one really gets close enough to the screens to notice the quality anyway.
ISPs won't make this mandatory unless most customers can support it and it provides some benefit for them. Most customers won't buy it unless it provides them with some other benefit or unless it's somehow marketed as a "good thing" despite masses of people crying foul. This is a catch 22.
The only way this will quickly come into practice is for a government to legislate a requirement for it. This will only affect the country in which the law is changed, and it will put that country at a disadvantage globally since the rest of the world will be able to operate on cheaper hardware and software without the trust requirement.
For these reasons I think your description is an ultimate worst-case scenario, and unlikely to arise in practice. What is more likely is that the trust chips will be used for more local restrictions such as supporting DRM on media files, and will thus be completely ignorable to anyone who is willing to forego the use of media files with DRM requirements. I've managed to survive without using media files with DRM requirements so far, and I don't see that changing any time soon.
While you are right that there is no legal way to get the XBox SDK to build these homebrew apps, once they are built it's a bit of a stretch to say that it's illegal to use them. The person who built the app is infringing copyright by using the SDK without a licence, but you don't need the SDK to actually run the result.
EMail addresses and IM addresses will never be identical without some layer of abstraction, because both expose some of the mechanics of how the messages are routed. In order for my Jabber ID to be the same as my email address, I must either manage my own domain -- which isn't an option for most people at this point -- or use the same provider for my email and my Jabber services. A user can choose to set things up this way for his own email address and Jabber ID, but no-one will ever be able to make the assumption that the two will always be identical.
Now what would be useful is some kind of service (decentralised, naturally) which gives every user a single identifier which can then be used to look up a user's Jabber ID or email address (or a webblog URL, telephone number...). Could even just use DNS for this with a few new RR types. People would probably want to do it in an authenticated manner though, so that they can control the distribution of their contact details; I guess things like LID can be used for this in theory. LID uses URLs as the universal identifier. Not much use until it gains critical mass, though.
The company I work at has two arms. There's an arm which develops bespoke software solutions for businesses, and these are generally Windows-based because that's what the company is already using or what the company knows about.
The other arm makes websites for local small businesses. This arm was created mostly as a little monetary prop-up between big software projects when the company was small. About a year ago an enterprising young web developer decided it'd be easier for him if he wrote a simple CMS to manage our website. Since this was not an officially-approved project and the website was running on a Plesk server at the time, he wrote the CMS in PHP using mySQL for the database. Once the boss got wind of this he decided it would be nice to use this software for client sites so that they could update their own stuff without having to come back to us.
A year on our CMS product has come on in leaps and bounds, and it is that I spend most of my time working on. However, it's like a little island of open source in an otherwise Microsoft world. Consequently, all of the development happens on Windows servers with the Windows version of Apache usually relegated to some non-standard port because IIS is in the way on port 80. There's only one non-Windows server in the whole place and it is not allocated for development. Open source gets a rough deal in my company, and I suspect the same is true in most places.
CSS already allows for only transferring the necessary stylesheet. In your HTML document you can specify which media types a given referenced stylesheet apply to and the browser can then determine which stylesheets are relevant to it. You still need to transfer the HTML document, but there shouldn't be any extraneous crap in the HTML document if the presentation is properly confined to the stylesheets anyway. (In practice there is usually a bit of "leakage" due to limitations of CSS2, but in most cases it's just a few extra DIVs and SPANs.
In this case it was probably a sensible choice. There are phones out there that only support the XHTML mobile profile or XHTML basic, and while they'll attempt to render normal XHTML documents they don't have a "tag-soup" parser available to try to render normal HTML. All of the latest phones have browsers capable of rendering normal pages (Opera with its small screen rendering, for example) but I think Google is also catering to the previous generation where XHTML support was just hacked on top of the WML (WAP markup) support using the existing XML parser.
Google should implement server-to-server but drop any incoming messages from users that are not on the recieving user's roster. This way people can still talk to their friends on other Jabber servers but unsolicited messages won't be a problem since they'll be dropped outright.
This may cause difficulties for agents that aren't people, such as services and bots, but at least it would open things up a little for person-to-person communication.