Ohad Eder-Pressman’s blog

here’s a scenario i’d like to have:

• i’m chatting with someone on IM
• i want to show him something i’m seeing on my screen
• i hit ctrl+apple+shift+whatever, get an overlay control to crop some part of my screen
• click my mouse, boom that part gets cropped and sent to my chat partner
• my chat partner gets a small message embedded into his chat dialog saying an image is being transferred with a progress bar
• when the image is transferred its shown as an inline thumbnail within the chat where the original message for ‘image being received’ was shown, this is chronological
• single-clicking the thumbnail brings up the entire image in a thin embedded viewer, no external stuff
• there’s a button to ’save to file’

i know i can screen-capture myself, save to a file, send to my friend, he accepts it, saves it to his hard drive and opens it with his default image viewer (which may be photoshop, OUCH). but we all know this flow sucks and that’s why we don’t do it.

what’s needed?

• IM protocol support for dynamic inline images (i think MSN has something like this, others?) this should enable injecting an image into the chat and later changing it. the whole process (image being sent, progress) can be done using solely with images.
• IM client support for capturing/cropping the screen and hiding the details from a the user while the data is being sent to his chat partner.

any ideas? if MSN supports enough of this in the protocol I vouch to get someone to write client support for this in Adium and maybe pidgin on windows.

It’s a known fact that CPU cores are not going to see high increases in their singular power. The alternative chip-makers have come up with is multi-core – the poor man’s SMP. It seems like future CPUs will be trying to maintain Moore’s law using more cores rather than more singular power.

Does this change the game? does it pose an opportunity?

It certainly forces hard-core programmers to focus on parallel-ability. Most programmers don’t deal with stuff that needs to be optimized (writing on_click handlers for buttons anybody?) but the core that writes our OSs‘, implements STL for us, writes graphic drivers, and the algorithmic type will have to keep up on their multi-threading skills.

The more popular programming languages have done a good job of not introducing multi-threaded concepts into their language structure. I say good because it has been generally unnecessary until now. What happens though if our PCs are suddenly all multi-core by definition? Do we expose this in high-level languages such as C#?

I wonder if we can reuse ideas from the distributed computing move of the past 10 years. I remember how in ‘98 I was thinking about the potential growth of distributed computing and how this growing field lacked tools to write parallel-able code…