Originally Posted by justchat_1
The only downside for web apps that i see is the lack of the ability to control hardware. While the w3c spec does have a geoLocation api, when your native you can just write a driver for whatever hardware you want. You can't go make drivers in a web app, you would need some kind of interface layer.
It's easy to overestimate what people will want in their cars. It's pretty amazing that GPS routing isn't a standard feature on every car. Voice, text and music are the only sure things. A smart phone with bluetooth takes care of the basics, and even now adds GPS.
The "carputer" may actually decline in popularity. iOSX and android put the pieces together more elegantly than any carputer. The trend is in the favor of the small, portable, touch screen OS.
Java was suppose to make hardware a commodity. Now browsers will replace OS. There's truth in this prediction, but it seems there will always be multiple ways of running software.
I run Rhapsody in a browser on Mac. But it's nicer as a win app where it can store music for offline play. When I'm traveling without 3G connection I can't play anything from the cloud.
Originally Posted by justchat_1
Why is it desktop applications still seem to run damn slow now even though CPU power has increased 1000 fold compared to the good old DOS days?
In fact no matter how fast the CPU gets,applications still seem to run at the same speed.
Sloppy code is one I can think of. In the old days with limited CPU power and memory access you had to write really tight code.
More graphical intense, yes this is true but why? To make it easier and more pleasing to the end user. And this could be a reason why Webbrowser apps may be the apps of the future, prettier and easier for the end user plus easier for novices to make their own apps.
And to make it easier for novices you tend to have generic routines whih can be dropped ino an app, great for ease of use, but because they are generic they may not be the most efficent way of doing it.
Sorry, just jotting things down as I think of them.
Carrying on discussing
Browser is really just a futher abstraction. It'll take a plugin specific to the OS to run that GPS from a browser. Then is it still a browser app?
Originally Posted by optikalefx
Big changes for "carputing" because of the huge battle brewing for control over location awareness. There are many billions of dollars at stake for whoever controls pushing advertising in that space. Google wants browser base so they can put it on the iphone without apples permission. Apple wants....the app store - the gate keeper.
At some level, don't forget that code still has to execute on a physical machine. So there's two different things being discussed here but as if they're one. And I think it serves well to separate the two:
2) "Presenting your application to the user through a browser, and have the actual work being done on a server"
Most modern "web applications" are some combination of those two in varying ratios. What you need to do for the car PC is create a shopping list of things that would be usefully done on a remote machine and what *must* be done locally. Then find the middleground. If that's something that makes sense to do as a browser based service, then great. If not, not so great.
Reading GPS data and rendering GPS voodoo. Reading positional data obviously *must* be done on the client. But there are explicit geolocation APIs available in browsers. The merits of this are clearly visible when you look at turn by turn directions handled via google maps.
Then there's other, arguably more devious, ways to look at this. Platform independance is a lot easier if you don't have to mess with GUI widgets. You could run your car application as a service on the PC, which listens on port 80. Then use your browser to connect to localhost:80. Something similar might be bugbyte using a sheevaplug for GPS, and then connecting to it from the other PC in his car, looking at it through a browser.
Other examples that immediately spring to mind of this are mediatomb and unreal tournament. Mediatomb has a web interface mainly as a way to implement a system agnostic way to manage your media. UT has it as a way to administer the game without having to resort to killing it and relaunching it with different options.
I'm specifically pondering doing this with my sheeva, bluetooth, and android phone. Perhaps obdgpslogger could listen on port eighty and return a webpage showing current status. Then the phone can render that. There's no lag involved because round trips are the time it takes a bluetooth signal to get a meter and back.
Abstracted, you're looking at being able to use arbitrary car PCs, screenless, and then connecting to them with a smartphone/tablet just as a way to render stuff - your browser in this scenario is mostly just a dumb renderer. Overall, it's arguably a "Web application".
Looking at it another way, exactly what gap is it that you're trying to fill? Google are using browsers to fill the "cross platform" gap. They run their actual application on what machines they want, and it works on any and all end user machines. Car PC owners clearly don't care about cross platform [developers such as justchat, trip, mal, me aside]. So what is so great about using the browser as a GUI platform that makes it better than a custom built dedicated tool?
Well, that's a braindump.
What Google and I think everyone else is forgetting is that in the future, we will all be running Linux on x86_64, so this OS and architecture abstraction idea is rather moot.
We'll just have to agree to disagree. It only has to run fast enough. In a few years, it will. Having 10X more CPU power is meaningless if it is fast enough. Maybe not efficient or elegant, but to the end user, whether it is running at 5, 50, or 95% doesn't make any difference unless it shows up in the interface or response time. If it is fast enough, it won't.
Originally Posted by justchat_1
Bravo! When can we get to work? :-)
Originally Posted by chunkyks
SO MANY THINGS ON MY PLATE
I had actually been thinking of writing a KML webservice type thing. Where it always just scrapes the last few samples in the database, and updates regularly. Maybe I'll try again. Hrm
Okay, let me chime in just because I'm opinionated.
1. Bandwidth cost is increasing, not decreasing. Unlimited plans will soon be a thing of the past.
2. That data centralization irks me. I don't like the idea that my phone, my car, my route, my pictures would all depending on how healthy Google Servers are. Or AT&T or whatever you trust in an emergency. I'm in earthquake country and I can lose cell data faster than anything else, even landlines. These things are simply not reliable.
3. I would like to see the opposite instead. Instead of increasing bandwidth, we're going to see an increase in local storage. I think (hope) that's the next breakthrough we're going to see for the future.
Everything that does not need to update on a regular basis (news, online gaming moves, video chat, etc.) will be local. Maps, pictures, applications will be local, you're not going to download anything, just acquire the license to use/make it available. If an app is developed, you'll have it available in time, even if you don't know about it.
At least that's what I'd rather see. Not likely, I know, but one can hope.