Iphone

Patents aside, byte ranges for JPEG 2000 is a nice idea, but doesn’t make practical sense because when you divide height and width by two, you also divide the number of bytes required by two—not four.

“A decent implementation of Web standards”. It is. I agree.

But why do you think they chose to write a developer guide?

In fact, their vibe is very similar to the stance taken by W3C and dotMobi: “It’s the web, but not exactly as you know it. Don’t go crazy”.

(By the way, the .mobi guidelines are W3C/web standards)

Since many other browsers are this good, and the .mobi TLD is primarily is about indicating user context anyway, your arguments about browser capabilities seem a bit old-fashioned.

I think we’ve been through this many times though

@Henri: I need a layman’s explanation. Patents aside, I want to be able to have scalable images. There must be a smart way of downloading a portion of an image you’re interested in. (Like I assume Apple does with its video technology)

@James: Just because it might be a W3C recommendation, doesn’t mean it’s any good. That’s why the WHATWG began. And yes, I don’t have time to get worked up about this poor “user context” argument of yours. Nice try.

Hehe

The web in 10 years time is going to be massively mobile and it’s going to be significantly different to today’s.

…in many ways, but particularly in the way that it will cater for mobile as a first-class context. I doubt much of the web will be designed solely for lonely folks sitting at big screens with lots of time on their hands.

Get out of your chair, walk about, but still be online – while you get on, efficiently, with the rest of your life!

I’ll see you then, and we will see who was right

And that handheld context will be accomplished with CSS. CSS made the Web suck less years ago and I hope it will do the same for mobiles. Fingers crossed.

As Russ says, I am waiting to be “liberated from the mobile web”!

Though I don’t have an Iphone and I’m stuck in an evil 18 month contract with my Nokia E65 and Three. When you get one James, can I play with it? Where you at Mobile Monday this week?

CSS manipulates form, not function.

I believe mobile users expect and deserve different function.

Nope; but I do help with MoMoDublin… do you want to come to the Emerald Isle and speak?

JP

The mobile device is a form of Web functionality.

Sure, I’d love to give a talk about the Web and mobile devices. I’ll let you know when I can make it up there.

Else, you could come to my talk about my business Webconverger at Minibar later this month. I would like to port Webconverger to mobile / embedded devices, though I lack the resources right now.

Suppose you have a JPEG 2000 image that is w pixels wide, h pixels high and b bytes in size. Suppose you want to load a version that is scaled down to being w/2 pixels wide and h/2 pixels high. If you re-encoded the image, you’d expect the scaled image to take b/4 bytes. However, if you want to get equivalent quality by reading the original JPEG 2000 image partially, you have to read roughly b/2 bytes, which is double compared to the re-encoded case.

I don’t know much about Image internals, so it is good of you to try explain them.

I wonder if this scaling inefficiency is the same as the use case of zooming into an image?

I am perhaps wrongly convinced that there must be a way of efficiently viewing bitmap images via network “byte-range requests”.

Joose points out I don’t know much about video containers either.

According to Joose ‘h264/aac’ is a standard and well implemented across different platforms.

As for size (bad), since Henri and Joose seems to think its the best way to do it, so I guess I can’t moan too much. Its just that resolutions will inevitably improve and change, so having all these videos targeting a certain resolution doesn’t leave us with a migration path. Another computing legacy I guess.

[...] use C, C++ and Python. No, you should be encourage developers to write Web applications, like the iphone. At the bottom of http://www.gnome.org/mobile/ there is hope… under Technologies for [...]

[...] similar to the iPhone, except without the voice comms [...]