IM protocols, do they support dynamic embedded images?

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.

Multi-Core Software

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...

Youtube Bucket testing?

Where are the goddamn iPhone SDK Rules

This one's been burning through 5 seconds of my brain's CPU a day. I keep thinking of what they are going to allow us to develop and what they won't. 5 seconds is not much btw, its about 0.0057% of my day, but still, you gotta have high standards.

Here is the damn PDF telling you what you can and can't do:
http://onemorething.nl/files/iphone_sdk_agt_608_final__wwdc08.pdf

Here's the part that pisses me off the most:

3.3.3 Without Apple’s prior written approval, an Application may not provide, unlock or enable additional features or functionality through distribution mechanisms other than the iTunes Store.

This basically bars us from providing downloadable content for sale. lets say you have a level-based games and you want to give away the game for free with additional level packs for sale (aka the console's way of making money). The current TOS won't let you do this.

Sure you can pack your premium content as a new game alltogether and put it on their store, I don't mind giving Apple their 30% cut of each level I sell, but give me a way to sell it with 1-click from within my game.

I'm sure they'll fix this asap.

mobile applications soon to come

so the upcoming wealth of iPhone applications is going to be amazing, i have no doubt whatsoever.

i was driving with jsherman this noon down to techshop in menlo park (which is pretty rad btw). we were blabbing about mobile apps, platforms and whatnot when we hit the upcoming iPhone.

everybody knows that the combination of data-always-on, GPS and semi-open-platform is going to create amazing stuff. i asked the question 'what would you do with built-in GPS and just the native apps?' guess what came up...

so, we all have meetings and whatnot in our calendar. i know that whenever i create an entry in my calendar i will usually create two alarms. one alarm will be a day in advance and the other will be, well, anywhere between 5 minutes and 2 hours before. your new iPhone is going to know where YOU are, its going to know where the MEETING will take place and its going to know how long it is before the meeting needs to take place. It could automatically let you know that you 'need to start getting ready because you need to leave to the meeting soon'.

how about your in traffic trying to figure out if you'll make it in time? i can never figure out what the social rules are, but i once read in this magazine my barber had that you can be up to five minutes late and its cool, you don't need to call. i guess in israel you can be up to 30 minutes late and still get by. it will take just a few lines of code and some heuristics for your iPhone to tell you that 'well, good points for trying to get to the meeting, but with your current speed it looks like your'e going to be late'.

what if your iphone would look each day to see if you have a meeting scheduled for lunch time the next day without a specific location and just popup to ask you 'interested in hearing about lunch places around?'

i remember in past years these ideas would popup every now and then. I remember eden shochat and yuval tal talking about intelligent personal assistants. The thing is these ideas used seem irrelevant because of the barrier to entry. they would always require sophisticated software (triangulating cell-towers, searching for local businesses) and usually inexistent hardware (always on data? gps). i think this is all changing, with the upcoming iPhone and with the existing Google APIs (maps, search...), I can't wait to be a happy user, and am super-interested in developing some of these things.

monetizing international users

that's it i'm starting to post musings on my blog, as in i just lowered the barrier of entry for my thoughts into this blog. and no, i will not google for pictures of the globe or of users and put them here for you or link things like facebook, this is pure informative peek into my few neurons :-)

i've been reading and noticing this a lot lately, people are talking about how unsure they are that they will be able to monetize international internet users compared to US ones.

this means most likely that US users have more cache, more easy infrastructure for paying (paypal), shipping, and consumerism in general, meaning its easier to opt them into to stuff and suck money from them.

for example, i just read that facebook's growth in the past year was mostly international and they are worried about not being able to monetize it.

it also spells opportunity, because if you can better monetize international users than the average ad-serving platform, you can be an easy drop-in for many sites/networks that have a large international crowd.

maybe its worth considering starting an ad-network focused on non-US markets... monetizing clicks and views in completely different ways.

is it time for a new architecture for mobile web-widget-thingies?

The new Google search for iPhone is AJAX'ish as it gets, well, almost.
You still need to load up the google page. The thing is, this main page is pretty static, why not try to cache it on the phone somehow and then get this awesome experience of just clicking 'google', then typing in your search terms and getting immediate results?

I bet y'all this can be done with a nifty bookmarklet which the iPhone's implementation of Safari should support...