Re: web based local application GUIs
Hi guys, Actually this problem indeed happened. and that was a bad thing to have closed (the scanner configuration etc) So we did solve the right way this time: no cross scanning, watch only user specified folders, uses a lot less memory, It's open source (in garage) and of course there's no more the configuration daemon that also gave us nightmares. The bad thing was to be closed, and work on simultaneos projects. About the CPU time, apart from the bug, in a bunch of test that we did it, when we turned off text scrolling our consumption was almost identical of the media player. So actually 2 devices fully powered playing a huge playlist in loop, the canola one died only a couple of minutes after the other. So just to clarify that was nothing but a BUG, like the thousand crashes we got just by playing media files in those first OSes. BR Marcelo On Nov 26, 2007 10:53 PM, Igor Stoppa [EMAIL PROTECTED] wrote: On Mon, 2007-11-26 at 15:31 -0500, ext Jesse Guardiani wrote: Let's please try to avoid stop energy in this thread. http://www.userland.com/whatIsStopEnergy Nice link. But I don't think it applies here. I _did_ propose an alternative. Of course you are free to ignore it, but your energy would be better spent if directed toward something useful. I'm just trying to help you avoid ending up in a Canola-like situation where, after you have delivered your nice application, somebody complains that the battery lasts nothing, we check what could be and then we find out that it's Canola sucking current all the time. On demand sounds great in theory, but let's think about it for a second: How do you start on-demand a web app? (HTTPD daemon) How do you play the next track when the current track finishes playing? (Kagu daemon, or FastCGI Kagu daemon + HTTPD daemon) Yes, that's the intrinsic problem of using an http-based approach. You rely on the http daemon being nice. Kagu is used very similar to a daemon. It runs as long as you're playing music. And if that's all you use an n800 for then it's always running. It might even be in the background if you're taking notes or browsing the web. The difference is that it has a GUI right now. I'd like to make that portion optional to save some memory/CPU when you aren't using it. I'd also like to make startup time faster, and I'd like to make a web frontend for it. Then you have to make sure that it will have 0% CPU residency, otherwise you'll be stealing playback time from your use-case. And you'll be taking memory no matter what, but hopefully not too much. Also, if you choose this approach, it is worth mentioning it in the release notes of your application, so that users don't get the false impression that your sw is harmless to battery life. No, I don't mean an always on daemon. I mean an on-demand daemon. A background process that runs when you need it and doesn't when you don't. I'm not a userland guy, but for what i remember, dbus should be able to start for you services that are not running, and dbus is _already_ running all the time. A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? -- Cheers, Igor Igor Stoppa [EMAIL PROTECTED] (Nokia Multimedia - CP - OSSO / Helsinki, Finland) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: web based local application GUIs
On Wed 05 Dec 2007 19:09, Kalle Valo [EMAIL PROTECTED] writes: ext Tomi Ollila [EMAIL PROTECTED] writes: So I remember incorrectly -- the real reason is (probably) that when socket(2) system call is started, these Internet Tablets tries to make internet connection up (either via wlan, or bt-connected phone) and if that cannot be made, socket(2) fails. There is no way knowing at socket(2) time that user wants to connect(2) 127.0/8 addresses. There is probably good reason to wrap socket() instead of connect(), bind() (and some other system calls.. timeouts maybe...). Nope, any of the calls you mentioned are not modified (or wrapped) in any way. They work similarly in Nokia tablets as in normal Linux PCs. In tablets applications request connections through libconic and after that they can open sockets as usual. If some applications request connections to localhost from libconic, that's a bug in the application, not in lower levels. OK! So next the big question: If I open default browser and try to connect http://127.0.0.1/ and I have application in port 80 serving http requests should that work? (with all / which IT OS versions?) Exception: there was a preload library (which name I don't even remember anymore) in osso-ic-lib which wrapped socket() and close() functions and did just what you described here. But I doubt (and hope) that nobody uses it anymore. What is someone wants to take some unix software, compile it unmodified for internet tables and expect it to make internet connections as the browser does now (i.e. automatically start connection over wlan/bt) ? -- Kalle Valo Thanks, Tomi ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: web based local application GUIs
ext Tomi Ollila [EMAIL PROTECTED] writes: On Wed 05 Dec 2007 19:09, Kalle Valo [EMAIL PROTECTED] writes: In tablets applications request connections through libconic and after that they can open sockets as usual. If some applications request connections to localhost from libconic, that's a bug in the application, not in lower levels. OK! So next the big question: If I open default browser and try to connect http://127.0.0.1/ and I have application in port 80 serving http requests should that work? (with all / which IT OS versions?) No idea, it depends how the browser is implemented. If it's clever enough, it won't request a connection from libconic for localhost connections. I'm not involved in browser development and I can't give you an answer for this one. Exception: there was a preload library (which name I don't even remember anymore) in osso-ic-lib which wrapped socket() and close() functions and did just what you described here. But I doubt (and hope) that nobody uses it anymore. What is someone wants to take some unix software, compile it unmodified for internet tables and expect it to make internet connections as the browser does now (i.e. automatically start connection over wlan/bt) ? Then the preload library is the only option. But in that case I think it's better that the user is forced to open the connection manually. The library is a hack and only deity knows what kind of problems it might create. When an application is really ported to maemo platform, it's trivial to add libconic support. This all is IMHO, of course. I finally checked the name of the preload library I have been talking about. It's libosso-ic-preload.so and doesn't seem to be included in OS2008 anymore. -- Kalle Valo ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: web based local application GUIs
ext Tomi Ollila [EMAIL PROTECTED] writes: So I remember incorrectly -- the real reason is (probably) that when socket(2) system call is started, these Internet Tablets tries to make internet connection up (either via wlan, or bt-connected phone) and if that cannot be made, socket(2) fails. There is no way knowing at socket(2) time that user wants to connect(2) 127.0/8 addresses. There is probably good reason to wrap socket() instead of connect(), bind() (and some other system calls.. timeouts maybe...). Nope, any of the calls you mentioned are not modified (or wrapped) in any way. They work similarly in Nokia tablets as in normal Linux PCs. In tablets applications request connections through libconic and after that they can open sockets as usual. If some applications request connections to localhost from libconic, that's a bug in the application, not in lower levels. Exception: there was a preload library (which name I don't even remember anymore) in osso-ic-lib which wrapped socket() and close() functions and did just what you described here. But I doubt (and hope) that nobody uses it anymore. -- Kalle Valo ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: web based local application GUIs
The network behavior on the tablet is really weird. When I connect to a bluetooth network with PAN, non-Nokia applications have no problem accessing the net. But the webbrowser still insists that there's no connection available. If I startup an adhoc wifi connection at the same time, Nokia applications can use the bluetooth network. Martin ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: web based local application GUIs
Hello, Tomi Ollila wrote: On Wed 28 Nov 2007 00:21, Aleksandr Koltsoff [EMAIL PROTECTED] writes: The lo interface is UP and running. You're right! By a coincidence I have both 770 and 800 on my desk now, neither running the latest OS version and both, indeed, have localhost interface up like the above (/sbin/ifconfig gives same output) So I remember incorrectly -- the real reason is (probably) that when socket(2) system call is started, these Internet Tablets tries to make internet connection up (either via wlan, or bt-connected phone) and if that cannot be made, socket(2) fails. There is no way knowing at socket(2) time that user wants to connect(2) 127.0/8 addresses. There is probably good reason to wrap socket() instead of connect(), bind() (and some other system calls.. timeouts maybe...). Well, I'm (quickly) writing this without checking earlier discussion of the matter. The situation is probably well-explained there (?). Ah yes, this does indeed sound slightly familiar back from the 1.0 days. Maybe a proper testing program is in order then. I might take a look at this later if I have spare time. If the syscall is wrapped, then yes, it would make things slightly difficult, but I'm wondering whether there's a simple way to avoid that even in that case. ak. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: web based local application GUIs
On Nov 27, 2007, at 23:12 , Jesse Guardiani wrote: On 11/27/07, Allan Doyle [EMAIL PROTECTED] wrote: One of our original ideas for the MWOW project (http://museum.mit.edu/mwow ) was to have the local web app talk to a local web proxy which then adds location info to the HTTP request and sends the request to a remote server. That way you can use the on-board linux tools to query a GPS, use wifi location, bluetooth beacons, etc. What are you using for a local web app? Anything I can play with? Using a proxy is pretty hard core. I probably would have been lazy and just used an iframe. We actually didn't go the proxy route for the first system because we had problems simultaneously using the WiFi radios for location detection and web access. You can find our somewhat stale code here: https://mwow.mit.edu/trac/mwow I've adapted the code to run on the 800 but have not done much else. I need to get back into some serious coding... I think microb is the way to go for my next go at this. Allan -- Jesse Guardiani Software Developer / Sys Admin [EMAIL PROTECTED] -- Allan Doyle Director of Technology MIT Museum +1.617.452.2111 ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: web based local application GUIs
So why not just port mpd server component to maemo and be done with it? Done. https://garage.maemo.org/projects/mpd There are 5 (five!) web based mpd clients listed on their site and 13 other ones. In addition meamo is already at, what, 4 - 5 media players? There is so much stuff out there talented developer like yourself can focus on... I think one thing that would help mpd on maemo would be implementing gstreamer support for it so it could decode using the dsp rather than the cpu. But otherwise, it works great. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: web based local application GUIs
On 11/27/07, Tomi Ollila [EMAIL PROTECTED] wrote: On Mon 26 Nov 2007 22:16, Igor Stoppa [EMAIL PROTECTED] writes: What's wrong with something that runs on-demand? A separate gui client which starts the server and browser on demand?...but LISCDNWiOM!! ;) lol. what? :) -- Jesse Guardiani Software Developer / Sys Admin [EMAIL PROTECTED] ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: web based local application GUIs
1.) Rpc (aka web services) 2.) Dbus 3.) Direct SQLite DB interaction Whatever motivation was, I second the idea to use 770/800/810 as device as user wants. Even smaller computers have place under the sun for more ambicious tasks. Web services could be love/hate, they solve the problem making different os-s share the project or business. Talking about web, I think ajax is nowadays must-have for success at first-time-visit customers. Btw, daemons and services could be less demanding than multimedia usage of the device. Zoran ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: web based local application GUIs
On 11/27/07, Zoran Kolic [EMAIL PROTECTED] wrote: 1.) Rpc (aka web services) 2.) Dbus 3.) Direct SQLite DB interaction Whatever motivation was, I second the idea to use 770/800/810 as device as user wants. Even smaller computers have place under the sun for more ambicious tasks. Web services could be love/hate, they solve the problem making different os-s share the project or business. Talking about web, I think ajax is nowadays must-have for success at first-time-visit customers. Btw, daemons and services could be less demanding than multimedia usage of the device. I don't agree with another always-on media daemon either. But an on-demand media daemon seems like the right fit. -- Jesse Guardiani Software Developer / Sys Admin [EMAIL PROTECTED] ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: web based local application GUIs
How about a GPS daemon similar to gpsd but with the capabiltiy to speak HTTP? Would be nice if people making webapps could include a javascript source from the localhost that would give back an object with GPS info. I've already written very lightweight implementations of this in Java and Python, however both rely on gpsd. I'm guessing one for the n810 could just call to the GPS APIs. I'm sure there will be security concerns, but it should be easy to turn off and on, and wouldn't be a big deal for a mobile device. The daemon also doesn't need to give a highly accurate latitude and longitude to still be very useful. Luis Zoran Kolic [EMAIL PROTECTED] wrote: 1.) Rpc (aka web services) 2.) Dbus 3.) Direct SQLite DB interaction Whatever motivation was, I second the idea to use 770/800/810 as device as user wants. Even smaller computers have place under the sun for more ambicious tasks. Web services could be love/hate, they solve the problem making different os-s share the project or business. Talking about web, I think ajax is nowadays must-have for success at first-time-visit customers. Btw, daemons and services could be less demanding than multimedia usage of the device. Zoran ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: web based local application GUIs
On Tue 27 Nov 2007 16:27, Jesse Guardiani [EMAIL PROTECTED] writes: On 11/27/07, Tomi Ollila [EMAIL PROTECTED] wrote: On Mon 26 Nov 2007 22:16, Igor Stoppa [EMAIL PROTECTED] writes: What's wrong with something that runs on-demand? A separate gui client which starts the server and browser on demand?...but LISCDNWiOM!! ;) lol. what? :) localhost inet sockets do not work in offline mode. Which, btw, is pretty weird (IMHO). I have not seen this behaviour in any other unix system; results of ifconfig lo 127.0.0.1 has preserved over changes in any other interfaces (static and dynamic). Why can not the loopback interface be up all the time ?? -- Jesse Guardiani Software Developer / Sys Admin [EMAIL PROTECTED] Tomi ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: web based local application GUIs
On 11/27/07, Tomi Ollila [EMAIL PROTECTED] wrote: On Tue 27 Nov 2007 16:27, Jesse Guardiani [EMAIL PROTECTED] writes: On 11/27/07, Tomi Ollila [EMAIL PROTECTED] wrote: On Mon 26 Nov 2007 22:16, Igor Stoppa [EMAIL PROTECTED] writes: What's wrong with something that runs on-demand? A separate gui client which starts the server and browser on demand?...but LISCDNWiOM!! ;) lol. what? :) localhost inet sockets do not work in offline mode. Which, btw, is pretty weird (IMHO). I have not seen this behaviour in any other unix system; results of ifconfig lo 127.0.0.1 has preserved over changes in any other interfaces (static and dynamic). Why can not the loopback interface be up all the time ?? Yeah, well, I guess that rules out web interfaces for userland applications, eh? shame... -- Jesse Guardiani Software Developer / Sys Admin [EMAIL PROTECTED] ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: web based local application GUIs
Jesse Guardiani [EMAIL PROTECTED] wrote: On 11/27/07, Tomi Ollila [EMAIL PROTECTED] wrote: On Tue 27 Nov 2007 16:27, Jesse Guardiani [EMAIL PROTECTED] writes: On 11/27/07, Tomi Ollila [EMAIL PROTECTED] wrote: On Mon 26 Nov 2007 22:16, Igor Stoppa [EMAIL PROTECTED] writes: What's wrong with something that runs on-demand? A separate gui client which starts the server and browser on demand?...but LISCDNWiOM!! ;) lol. what? :) localhost inet sockets do not work in offline mode. Which, btw, is pretty weird (IMHO). I have not seen this behaviour in any other unix system; results of ifconfig lo 127.0.0.1 has preserved over changes in any other interfaces (static and dynamic). Why can not the loopback interface be up all the time ?? Yeah, well, I guess that rules out web interfaces for userland applications, eh? shame... -- Jesse Guardiani Software Developer / Sys Admin [EMAIL PROTECTED] Sounds more like a bug that needs fixing rather than something to rule out. Luis ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: web based local application GUIs
On Nov 27, 2007, at 16:31 , [EMAIL PROTECTED] wrote: Jesse Guardiani [EMAIL PROTECTED] wrote: On 11/27/07, Tomi Ollila [EMAIL PROTECTED] wrote: On Tue 27 Nov 2007 16:27, Jesse Guardiani [EMAIL PROTECTED] writes: On 11/27/07, Tomi Ollila [EMAIL PROTECTED] wrote: On Mon 26 Nov 2007 22:16, Igor Stoppa [EMAIL PROTECTED] writes: What's wrong with something that runs on-demand? A separate gui client which starts the server and browser on demand?...but LISCDNWiOM!! ;) lol. what? :) localhost inet sockets do not work in offline mode. Which, btw, is pretty weird (IMHO). I have not seen this behaviour in any other unix system; results of ifconfig lo 127.0.0.1 has preserved over changes in any other interfaces (static and dynamic). Why can not the loopback interface be up all the time ?? Yeah, well, I guess that rules out web interfaces for userland applications, eh? shame... -- Jesse Guardiani Software Developer / Sys Admin [EMAIL PROTECTED] Sounds more like a bug that needs fixing rather than something to rule out. Luis This has been an issue for a long time: https://bugs.maemo.org/show_bug.cgi?id=339 http://lists.maemo.org/pipermail/maemo-developers/2007-May/010076.html I guess this thread is doomed to recur every 6 months or so... Allan -- Allan Doyle Director of Technology MIT Museum +1.617.452.2111 ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: web based local application GUIs
that's typically an indicator that it needs to be fixed. On 11/27/07, Allan Doyle [EMAIL PROTECTED] wrote: On Nov 27, 2007, at 16:31 , [EMAIL PROTECTED] wrote: Jesse Guardiani [EMAIL PROTECTED] wrote: On 11/27/07, Tomi Ollila [EMAIL PROTECTED] wrote: On Tue 27 Nov 2007 16:27, Jesse Guardiani [EMAIL PROTECTED] writes: On 11/27/07, Tomi Ollila [EMAIL PROTECTED] wrote: On Mon 26 Nov 2007 22:16, Igor Stoppa [EMAIL PROTECTED] writes: What's wrong with something that runs on-demand? A separate gui client which starts the server and browser on demand?...but LISCDNWiOM!! ;) lol. what? :) localhost inet sockets do not work in offline mode. Which, btw, is pretty weird (IMHO). I have not seen this behaviour in any other unix system; results of ifconfig lo 127.0.0.1 has preserved over changes in any other interfaces (static and dynamic). Why can not the loopback interface be up all the time ?? Yeah, well, I guess that rules out web interfaces for userland applications, eh? shame... -- Jesse Guardiani Software Developer / Sys Admin [EMAIL PROTECTED] Sounds more like a bug that needs fixing rather than something to rule out. Luis This has been an issue for a long time: https://bugs.maemo.org/show_bug.cgi?id=339 http://lists.maemo.org/pipermail/maemo-developers/2007-May/010076.html I guess this thread is doomed to recur every 6 months or so... Allan -- Allan Doyle Director of Technology MIT Museum +1.617.452.2111 ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers -- Jesse Guardiani Software Developer / Sys Admin [EMAIL PROTECTED] ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: web based local application GUIs
Meanwhile, Microsoft teamed with Sprint 3 months ago to provide web applications that are location aware: http://www2.sprint.com/mr/news_dtl.do?id=18020 The same sort of thing is attainable on an N810 using open standards when the connection is live, but the point still stands that the local service should be available offline. Jesse Guardiani [EMAIL PROTECTED] wrote: that's typically an indicator that it needs to be fixed. On 11/27/07, Allan Doyle [EMAIL PROTECTED] wrote: On Nov 27, 2007, at 16:31 , [EMAIL PROTECTED] wrote: Jesse Guardiani [EMAIL PROTECTED] wrote: On 11/27/07, Tomi Ollila [EMAIL PROTECTED] wrote: On Tue 27 Nov 2007 16:27, Jesse Guardiani [EMAIL PROTECTED] writes: On 11/27/07, Tomi Ollila [EMAIL PROTECTED] wrote: On Mon 26 Nov 2007 22:16, Igor Stoppa [EMAIL PROTECTED] writes: What's wrong with something that runs on-demand? A separate gui client which starts the server and browser on demand?...but LISCDNWiOM!! ;) lol. what? :) localhost inet sockets do not work in offline mode. Which, btw, is pretty weird (IMHO). I have not seen this behaviour in any other unix system; results of ifconfig lo 127.0.0.1 has preserved over changes in any other interfaces (static and dynamic). Why can not the loopback interface be up all the time ?? Yeah, well, I guess that rules out web interfaces for userland applications, eh? shame... -- Jesse Guardiani Software Developer / Sys Admin [EMAIL PROTECTED] Sounds more like a bug that needs fixing rather than something to rule out. Luis This has been an issue for a long time: https://bugs.maemo.org/show_bug.cgi?id=339 http://lists.maemo.org/pipermail/maemo-developers/2007-May/010076.html I guess this thread is doomed to recur every 6 months or so... Allan -- Allan Doyle Director of Technology MIT Museum +1.617.452.2111 ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers -- Jesse Guardiani Software Developer / Sys Admin [EMAIL PROTECTED] ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: web based local application GUIs
Hi, This has been an issue for a long time: https://bugs.maemo.org/show_bug.cgi?id=339 http://lists.maemo.org/pipermail/maemo-developers/2007-May/010076.html I guess this thread is doomed to recur every 6 months or so... Oh yeah, every now and then, somebody raises this issue. I originally posted this bug report back in 2005 because I just wanted to run a moinmoin wiki on my 770. I still can't do that even today. :( I totally gave up on this idea... Cheers, Martin ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: web based local application GUIs
Hi, GPS-enabled search tool has been incorporated by Google under name local search in last few years. Ok. Voice search makes it a minor novelty. Major problem is if What You Want is What You Get (service mark by Darius) really works. Internet is not more global village as paid indexing is what generates more and more money. To Allan. Do you have any items from MediaMoo, Microworlds, GNA at your MIT Museum ? Darius [EMAIL PROTECTED] wrote: Meanwhile, Microsoft teamed with Sprint 3 months ago to provide web applications that are location aware: http://www2.sprint.com/mr/news_dtl.do?id=18020 The same sort of thing is attainable on an N810 using open standards when the connection is live, but the point still stands that the local service should be available offline. Jesse Guardiani wrote: that's typically an indicator that it needs to be fixed. On 11/27/07, Allan Doyle wrote: On Nov 27, 2007, at 16:31 , wrote: Jesse Guardiani wrote: On 11/27/07, Tomi Ollila wrote: On Tue 27 Nov 2007 16:27, Jesse Guardiani writes: On 11/27/07, Tomi Ollila wrote: On Mon 26 Nov 2007 22:16, Igor Stoppa writes: What's wrong with something that runs on-demand? A separate gui client which starts the server and browser on demand?...but LISCDNWiOM!! ;) lol. what? :) localhost inet sockets do not work in offline mode. Which, btw, is pretty weird (IMHO). I have not seen this behaviour in any other unix system; results of ifconfig lo 127.0.0.1 has preserved over changes in any other interfaces (static and dynamic). Why can not the loopback interface be up all the time ?? Yeah, well, I guess that rules out web interfaces for userland applications, eh? shame... -- Jesse Guardiani Software Developer / Sys Admin [EMAIL PROTECTED] Sounds more like a bug that needs fixing rather than something to rule out. Luis This has been an issue for a long time: https://bugs.maemo.org/show_bug.cgi?id=339 http://lists.maemo.org/pipermail/maemo-developers/2007-May/010076.html I guess this thread is doomed to recur every 6 months or so... Allan -- Allan Doyle Director of Technology MIT Museum +1.617.452.2111 ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers -- Jesse Guardiani Software Developer / Sys Admin [EMAIL PROTECTED] ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers Send instant messages to your online friends http://uk.messenger.yahoo.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: web based local application GUIs
local search will not talk to the GPS unit connected to a 770,800,or 810. You can go to local.google.com and put in a location, then do something like search for the nearest pizza point. Works great. Also some windows mobile and j2me phones/PDAs can download a google maps app that talks to the gps device. But what I'm talking about is a standard that any website can use automatically by embedding something like script src=http://localhost:2947/gpsinfo; into their page and getting back a javascript object with the latitude longitude info. Luis Darius Jack [EMAIL PROTECTED] wrote: Hi, GPS-enabled search tool has been incorporated by Google under name local search in last few years. Ok. Voice search makes it a minor novelty. Major problem is if What You Want is What You Get (service mark by Darius) really works. Internet is not more global village as paid indexing is what generates more and more money. To Allan. Do you have any items from MediaMoo, Microworlds, GNA at your MIT Museum ? Darius [EMAIL PROTECTED] wrote: Meanwhile, Microsoft teamed with Sprint 3 months ago to provide web applications that are location aware: http://www2.sprint.com/mr/news_dtl.do?id=18020 The same sort of thing is attainable on an N810 using open standards when the connection is live, but the point still stands that the local service should be available offline. Jesse Guardiani wrote: that's typically an indicator that it needs to be fixed. On 11/27/07, Allan Doyle wrote: On Nov 27, 2007, at 16:31 , wrote: Jesse Guardiani wrote: On 11/27/07, Tomi Ollila wrote: On Tue 27 Nov 2007 16:27, Jesse Guardiani writes: On 11/27/07, Tomi Ollila wrote: On Mon 26 Nov 2007 22:16, Igor Stoppa writes: What's wrong with something that runs on-demand? A separate gui client which starts the server and browser on demand?...but LISCDNWiOM!! ;) lol. what? :) localhost inet sockets do not work in offline mode. Which, btw, is pretty weird (IMHO). I have not seen this behaviour in any other unix system; results of ifconfig lo 127.0.0.1 has preserved over changes in any other interfaces (static and dynamic). Why can not the loopback interface be up all the time ?? Yeah, well, I guess that rules out web interfaces for userland applications, eh? shame... -- Jesse Guardiani Software Developer / Sys Admin [EMAIL PROTECTED] Sounds more like a bug that needs fixing rather than something to rule out. Luis This has been an issue for a long time: https://bugs.maemo.org/show_bug.cgi?id=339 http://lists.maemo.org/pipermail/maemo-developers/2007-May/010076.html I guess this thread is doomed to recur every 6 months or so... Allan -- Allan Doyle Director of Technology MIT Museum +1.617.452.2111 ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers -- Jesse Guardiani Software Developer / Sys Admin [EMAIL PROTECTED] ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers Send instant messages to your online friends http://uk.messenger.yahoo.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: web based local application GUIs
Hi, why not ? It's a very popular gps monitoring application to send gps data to www server from gps-enabled cell phone, over GPRS. It works fine for car, personal monitoring. 2 years ago I run such server and could watch tracks of 100 car live in maps application. There is nothing special to send gps data that way. To have local search you can run middle-server communicating with Google local and Nokia tablet, residing gps data and query string and sending back search results. Why do you mean to introduce your idea as a standard ? Some ppl need some privacy from time to time. There is another solution. Under latest EUC proposal operator of cell phone and manufacturer of sim card could be obliged to incorporate gps chip into sim card to let operators of alarm phone to know exact geoposition of a calling party on a map. Another idea and solution already known in PDA +cell phone + gps market. I see no problem to incorporate your ideas into N770, N800, N810 (not smartphones). Darius [EMAIL PROTECTED] wrote: local search will not talk to the GPS unit connected to a 770,800,or 810. You can go to local.google.com and put in a location, then do something like search for the nearest pizza point. Works great. Also some windows mobile and j2me phones/PDAs can download a google maps app that talks to the gps device. But what I'm talking about is a standard that any website can use automatically by embedding something like into their page and getting back a javascript object with the latitude longitude info. Luis Darius Jack wrote: Hi, GPS-enabled search tool has been incorporated by Google under name local search in last few years. Ok. Voice search makes it a minor novelty. Major problem is if What You Want is What You Get (service mark by Darius) really works. Internet is not more global village as paid indexing is what generates more and more money. To Allan. Do you have any items from MediaMoo, Microworlds, GNA at your MIT Museum ? Darius [EMAIL PROTECTED] wrote: Meanwhile, Microsoft teamed with Sprint 3 months ago to provide web applications that are location aware: http://www2.sprint.com/mr/news_dtl.do?id=18020 The same sort of thing is attainable on an N810 using open standards when the connection is live, but the point still stands that the local service should be available offline. Jesse Guardiani wrote: that's typically an indicator that it needs to be fixed. On 11/27/07, Allan Doyle wrote: On Nov 27, 2007, at 16:31 , wrote: Jesse Guardiani wrote: On 11/27/07, Tomi Ollila wrote: On Tue 27 Nov 2007 16:27, Jesse Guardiani writes: On 11/27/07, Tomi Ollila wrote: On Mon 26 Nov 2007 22:16, Igor Stoppa writes: What's wrong with something that runs on-demand? A separate gui client which starts the server and browser on demand?...but LISCDNWiOM!! ;) lol. what? :) localhost inet sockets do not work in offline mode. Which, btw, is pretty weird (IMHO). I have not seen this behaviour in any other unix system; results of ifconfig lo 127.0.0.1 has preserved over changes in any other interfaces (static and dynamic). Why can not the loopback interface be up all the time ?? Yeah, well, I guess that rules out web interfaces for userland applications, eh? shame... -- Jesse Guardiani Software Developer / Sys Admin [EMAIL PROTECTED] Sounds more like a bug that needs fixing rather than something to rule out. Luis This has been an issue for a long time: https://bugs.maemo.org/show_bug.cgi?id=339 http://lists.maemo.org/pipermail/maemo-developers/2007-May/010076.html I guess this thread is doomed to recur every 6 months or so... Allan -- Allan Doyle Director of Technology MIT Museum +1.617.452.2111 ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers -- Jesse Guardiani Software Developer / Sys Admin [EMAIL PROTECTED] ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers Send instant messages to your online friends http://uk.messenger.yahoo.com Send instant messages to your online friends http://uk.messenger.yahoo.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: web based local application GUIs
One of our original ideas for the MWOW project (http://museum.mit.edu/mwow ) was to have the local web app talk to a local web proxy which then adds location info to the HTTP request and sends the request to a remote server. That way you can use the on-board linux tools to query a GPS, use wifi location, bluetooth beacons, etc. The thing that immediately got in the way (on the 770) was that if you were actually connected to a WiFi access point, the ability to read signal strengths from the wifi radio got worse. Also, using the iwtools would cause the connection to drop some of the time. Regarding standards - there is the GeoClue project (http://www.freedesktop.org/wiki/Software/GeoClue ) which tries to hide the locationing device details under a uniform interface. On the search side, there are no real standards for how to construct the geo portion of a search. OpenSearch does have a geo extension proposal (http://www.opensearch.org/Specifications/OpenSearch/Extensions/Geo/1.0/Draft_1 ) And, Darius, regarding your question about the MIT Museum, no we don't have anything from those projects/groups but we do have other cool stuff. Stop by if you're in the Boston area! Allan On Nov 27, 2007, at 19:29 , Darius Jack wrote: Hi, why not ? It's a very popular gps monitoring application to send gps data to www server from gps-enabled cell phone, over GPRS. It works fine for car, personal monitoring. 2 years ago I run such server and could watch tracks of 100 car live in maps application. There is nothing special to send gps data that way. To have local search you can run middle-server communicating with Google local and Nokia tablet, residing gps data and query string and sending back search results. Why do you mean to introduce your idea as a standard ? Some ppl need some privacy from time to time. There is another solution. Under latest EUC proposal operator of cell phone and manufacturer of sim card could be obliged to incorporate gps chip into sim card to let operators of alarm phone to know exact geoposition of a calling party on a map. Another idea and solution already known in PDA +cell phone + gps market. I see no problem to incorporate your ideas into N770, N800, N810 (not smartphones). Darius [EMAIL PROTECTED] wrote: local search will not talk to the GPS unit connected to a 770,800,or 810. You can go to local.google.com and put in a location, then do something like search for the nearest pizza point. Works great. Also some windows mobile and j2me phones/PDAs can download a google maps app that talks to the gps device. But what I'm talking about is a standard that any website can use automatically by embedding something like into their page and getting back a javascript object with the latitude longitude info. Luis Darius Jack wrote: Hi, GPS-enabled search tool has been incorporated by Google under name local search in last few years. Ok. Voice search makes it a minor novelty. Major problem is if What You Want is What You Get (service mark by Darius) really works. Internet is not more global village as paid indexing is what generates more and more money. To Allan. Do you have any items from MediaMoo, Microworlds, GNA at your MIT Museum ? Darius [... rest cut to stay below the 20K limit imposed by lists.maemo.org ...] -- Allan Doyle Director of Technology MIT Museum +1.617.452.2111 ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: web based local application GUIs
On 11/27/07, Allan Doyle [EMAIL PROTECTED] wrote: One of our original ideas for the MWOW project (http://museum.mit.edu/mwow) was to have the local web app talk to a local web proxy which then adds location info to the HTTP request and sends the request to a remote server. That way you can use the on-board linux tools to query a GPS, use wifi location, bluetooth beacons, etc. What are you using for a local web app? Anything I can play with? Using a proxy is pretty hard core. I probably would have been lazy and just used an iframe. -- Jesse Guardiani Software Developer / Sys Admin [EMAIL PROTECTED] ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: web based local application GUIs
On Wed 28 Nov 2007 00:21, Aleksandr Koltsoff [EMAIL PROTECTED] writes: For some reason can't find the mail that had the below quoted part, but anyways: On 11/27/07, Tomi Ollila [EMAIL PROTECTED] wrote: Why can not the loopback interface be up all the time ?? Tested on N810 just a moment ago: 1) put device in flight mode 2) /sbin/ifconfig loLink encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:38 errors:0 dropped:0 overruns:0 frame:0 TX packets:38 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:14929 (14.5 KiB) TX bytes:14929 (14.5 KiB) The lo interface is UP and running. If by inet socks not working you mean localhost not resolving to 127.0.0.1, then say so. The lo interface seems to be running and well. You're right! By a coincidence I have both 770 and 800 on my desk now, neither running the latest OS version and both, indeed, have localhost interface up like the above (/sbin/ifconfig gives same output) So I remember incorrectly -- the real reason is (probably) that when socket(2) system call is started, these Internet Tablets tries to make internet connection up (either via wlan, or bt-connected phone) and if that cannot be made, socket(2) fails. There is no way knowing at socket(2) time that user wants to connect(2) 127.0/8 addresses. There is probably good reason to wrap socket() instead of connect(), bind() (and some other system calls.. timeouts maybe...). Well, I'm (quickly) writing this without checking earlier discussion of the matter. The situation is probably well-explained there (?). ak. Tomi ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
web based local application GUIs
I've been thinking a lot lately about Kagu Media Player's future. The project has come a long way and all of us devs have learned a lot in the process. But Canola is coming out soon (or so it seems) and we're reaching the limit of what is maintainable with a pygame based UI. I've decided that I'd really like to separate the frontend code from the backend code so we can have multiple frontends (pygame, gtk, etk, cli, WWW, etc). This would mean that the Kagu backend process would be a daemon (aka a service, depending on your education environment). And the frontends would communicate with the backend process somehow. I see a few possibilities here: 1.) Rpc (aka web services) 2.) Dbus 3.) Direct SQLite DB interaction Dbus seems like an obvious choice, but Kagu would be incredibly chatty and I'm not sure if Dbus is capable of handling the bandwidth. In addition, dbus would limit GUIs to running on the device itself, rather than the world at large. This isn't necessarily a bad thing, but it's something to consider. SQLite is the least friendly method, IMO, as it involves file locking and other nastiness. No thanks. Rpc seems like the best overall choice, but how common is Rpc on Maemo? The other concern I have is process management of the backend Kagu daemon. How will it be started? How will it be stopped? A GTK, PyGame, ETK, or even CLI client could start the Kagu daemon for us. But what about a WWW client? Is there any way to start the daemon simply by accessing a URL, like http://localhost/kagu ? If Apache was installed on the device then an apache script (mod_php or mod_python) could start the daemon for us and proxy any requests. But that seems too bulky of a solution. I've seen this page discussing WWW applications as local applications on Maemo: http://maemo.org/community/wiki/serverbrowserappdevelopment/ But I couldn't find the mailing list discussion it references. Any suggestions for these problems? Any ideas? Comments? Thanks! -- Jesse Guardiani Software Developer / Sys Admin [EMAIL PROTECTED] ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: web based local application GUIs
Jesse Guardiani jesse at guardiani.us writes: I've seen this page discussing WWW applications as local applications on Maemo: http://maemo.org/community/wiki/serverbrowserappdevelopment/ But I couldn't find the mailing list discussion it references. Another good URL along the same lines: http://paulmostardi.com/blog/2007/Apr/05/2/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: web based local application GUIs
Hi, On Mon, 2007-11-26 at 13:11 -0500, ext Jesse Guardiani wrote: [snip] This would mean that the Kagu backend process would be a daemon (aka a service, depending on your education environment). If possible, please no, not another daemon. We are already plagued by a large number of (mostly unnecessary!) daemons (i don't remember on top of my head how many exactly, but it's a 2 digits figure) that have trickled over the years in the standard stack. The metacrawler is a good example of why you don't want to write a daemon. To write a daemon is to ask for trouble since your sw will use memory, cpu time and power all the time. Also bugs will be more critical. What's wrong with something that runs on-demand? Unless you rely on having dbus to start and stop the service ... that would probably be ok. -- Cheers, Igor Igor Stoppa [EMAIL PROTECTED] (Nokia Multimedia - CP - OSSO / Helsinki, Finland) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: web based local application GUIs
Let's please try to avoid stop energy in this thread. http://www.userland.com/whatIsStopEnergy On demand sounds great in theory, but let's think about it for a second: How do you start on-demand a web app? (HTTPD daemon) How do you play the next track when the current track finishes playing? (Kagu daemon, or FastCGI Kagu daemon + HTTPD daemon) Kagu is used very similar to a daemon. It runs as long as you're playing music. And if that's all you use an n800 for then it's always running. It might even be in the background if you're taking notes or browsing the web. The difference is that it has a GUI right now. I'd like to make that portion optional to save some memory/CPU when you aren't using it. I'd also like to make startup time faster, and I'd like to make a web frontend for it. No, I don't mean an always on daemon. I mean an on-demand daemon. A background process that runs when you need it and doesn't when you don't. On 11/26/07, Igor Stoppa [EMAIL PROTECTED] wrote: Hi, On Mon, 2007-11-26 at 13:11 -0500, ext Jesse Guardiani wrote: [snip] This would mean that the Kagu backend process would be a daemon (aka a service, depending on your education environment). If possible, please no, not another daemon. We are already plagued by a large number of (mostly unnecessary!) daemons (i don't remember on top of my head how many exactly, but it's a 2 digits figure) that have trickled over the years in the standard stack. The metacrawler is a good example of why you don't want to write a daemon. To write a daemon is to ask for trouble since your sw will use memory, cpu time and power all the time. Also bugs will be more critical. What's wrong with something that runs on-demand? Unless you rely on having dbus to start and stop the service ... that would probably be ok. -- Cheers, Igor Igor Stoppa [EMAIL PROTECTED] (Nokia Multimedia - CP - OSSO / Helsinki, Finland) -- Jesse Guardiani Software Developer / Sys Admin [EMAIL PROTECTED] ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: web based local application GUIs
On Mon, 2007-11-26 at 15:31 -0500, ext Jesse Guardiani wrote: Let's please try to avoid stop energy in this thread. http://www.userland.com/whatIsStopEnergy Nice link. But I don't think it applies here. I _did_ propose an alternative. Of course you are free to ignore it, but your energy would be better spent if directed toward something useful. I'm just trying to help you avoid ending up in a Canola-like situation where, after you have delivered your nice application, somebody complains that the battery lasts nothing, we check what could be and then we find out that it's Canola sucking current all the time. On demand sounds great in theory, but let's think about it for a second: How do you start on-demand a web app? (HTTPD daemon) How do you play the next track when the current track finishes playing? (Kagu daemon, or FastCGI Kagu daemon + HTTPD daemon) Yes, that's the intrinsic problem of using an http-based approach. You rely on the http daemon being nice. Kagu is used very similar to a daemon. It runs as long as you're playing music. And if that's all you use an n800 for then it's always running. It might even be in the background if you're taking notes or browsing the web. The difference is that it has a GUI right now. I'd like to make that portion optional to save some memory/CPU when you aren't using it. I'd also like to make startup time faster, and I'd like to make a web frontend for it. Then you have to make sure that it will have 0% CPU residency, otherwise you'll be stealing playback time from your use-case. And you'll be taking memory no matter what, but hopefully not too much. Also, if you choose this approach, it is worth mentioning it in the release notes of your application, so that users don't get the false impression that your sw is harmless to battery life. No, I don't mean an always on daemon. I mean an on-demand daemon. A background process that runs when you need it and doesn't when you don't. I'm not a userland guy, but for what i remember, dbus should be able to start for you services that are not running, and dbus is _already_ running all the time. A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? -- Cheers, Igor Igor Stoppa [EMAIL PROTECTED] (Nokia Multimedia - CP - OSSO / Helsinki, Finland) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: web based local application GUIs
On 11/26/07, Igor Stoppa [EMAIL PROTECTED] wrote: On demand sounds great in theory, but let's think about it for a second: How do you start on-demand a web app? (HTTPD daemon) How do you play the next track when the current track finishes playing? (Kagu daemon, or FastCGI Kagu daemon + HTTPD daemon) Yes, that's the intrinsic problem of using an http-based approach. You rely on the http daemon being nice. You gain a lot from having an HTTP daemon though. You gain a consistent GUI (html + browser) and a common development methodology (web application development) that many programmers are already intimately familiar with. You also gain the ability to use a high level language for GUI work while still having a very fast startup time (theoretically, I haven't tried it yet). You gain the ability to use CSS for application theming. You also gain portability. No more wondering why the strange PyGtk Hildonization hack you had to do back in Bora no longer works in Chinook. In fact, you no longer care if you're on chinook, bora, gregale, or the internet at large. It doesn't matter. All you need is a web server and a web browser and you're good to go. Kagu is used very similar to a daemon. It runs as long as you're playing music. And if that's all you use an n800 for then it's always running. It might even be in the background if you're taking notes or browsing the web. The difference is that it has a GUI right now. I'd like to make that portion optional to save some memory/CPU when you aren't using it. I'd also like to make startup time faster, and I'd like to make a web frontend for it. Then you have to make sure that it will have 0% CPU residency, otherwise you'll be stealing playback time from your use-case. And you'll be taking memory no matter what, but hopefully not too much. Yes. I've already written Kagu using pygame. I've had to deal with CPU utilization and playback more than I'd like to admit. It would be significantly easier to handle without a GUI because I wouldn't have to worry about maintaining a consistent frame rate in pygame at the same time. Also, if you choose this approach, it is worth mentioning it in the release notes of your application, so that users don't get the false impression that your sw is harmless to battery life. meh. Never mentioned it in Kagu. Once I screwed it up and people complained. We fixed it quickly and people forgot it ever happened. That's just another useful thing about using a browser for a GUI IMO. No, I don't mean an always on daemon. I mean an on-demand daemon. A background process that runs when you need it and doesn't when you don't. I'm not a userland guy, but for what i remember, dbus should be able to start for you services that are not running, and dbus is _already_ running all the time. Hey, there's a useful bit of info! Thanks! I forgot all about that. So the Kagu daemon could be started via dbus and kill itself when it runs out of useful work to do. The frontend could then run using the normal mod_php mentality (page based) and start the backend automatically using dbus when it needs it, continuing to query via dbus any time it needs to communicate. -- Jesse Guardiani Software Developer / Sys Admin [EMAIL PROTECTED] ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: web based local application GUIs
I've decided that I'd really like to separate the frontend code from the backend code so we can have multiple frontends (pygame, gtk, etk, cli, WWW, etc). This would mean that the Kagu backend process would be a daemon (aka a service, depending on your education environment). And the frontends would communicate with the backend process somehow. I see a few possibilities here: 1.) Rpc (aka web services) 2.) Dbus 3.) Direct SQLite DB interaction I think this is a great idea. I personally use mpd just for this reason. In fact, why not just use the mpd protocol over net sockets? You'd immediately get a ridiculously large number of front-end clients and it would work over the net: http://mpd.wikia.com/wiki/Clients ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: web based local application GUIs
Jesse, Not trying to throw stop energy into the mix, just reflecting on some of your points. You did ask for comments. So here are a few. :-) On 11/26/07, Jesse Guardiani [EMAIL PROTECTED] wrote: On 11/26/07, Igor Stoppa [EMAIL PROTECTED] wrote: On demand sounds great in theory, but let's think about it for a second: How do you start on-demand a web app? (HTTPD daemon) How do you play the next track when the current track finishes playing? (Kagu daemon, or FastCGI Kagu daemon + HTTPD daemon) Yes, that's the intrinsic problem of using an http-based approach. You rely on the http daemon being nice. You gain a lot from having an HTTP daemon though. You gain a consistent GUI (html + browser) and a common development methodology (web application development) that many programmers are already intimately familiar with. I would have to disagree on the consistency point. I spent three years doing n-tier database applications development with web based frontends, and getting a consistent look and feel (let alone functionality) across multiple OS/browser platforms can be _very_ difficult. Especially with all of the various security functions that users employ to protect themselves from nefarious scripts. In the end we gave up and targeted Windows only. I was very sad but we spent a _huge_ number of man hours trying to make it work. You also gain the ability to use a high level language for GUI work while still having a very fast startup time (theoretically, I haven't tried it yet). While I agree with you for the majority of processors out there (1GHz or faster with lots of memory) the Nokia tablets are not so good in comparison at client side web application execution (think Web 2.0 or tons of JavaScript). Gmail with AJAX is pretty hard to use on my N800 (I have since given up), maybe it will be doable on my N810. You gain the ability to use CSS for application theming. You also gain portability. No more wondering why the strange PyGtk Hildonization hack you had to do back in Bora no longer works in Chinook. In fact, you no longer care if you're on chinook, bora, gregale, or the internet at large. It doesn't matter. All you need is a web server and a web browser and you're good to go. I have read that GTK portability is good, and in my limited experience was good across Windows, Linux, and Mac OS X. This is one of the reasons I have chosen it for the applications I am working on. Is the problem you are experiencing a function of the advanced interface work you are doing or is it truly a problem with the GTK/Hildon environment changing? Maybe with some other developers working on that problem the need for an n-tier application structure will go away? Kagu is used very similar to a daemon. It runs as long as you're playing music. And if that's all you use an n800 for then it's always running. It might even be in the background if you're taking notes or browsing the web. The difference is that it has a GUI right now. I'd like to make that portion optional to save some memory/CPU when you aren't using it. I'd also like to make startup time faster, and I'd like to make a web frontend for it. Do you intend on having the server portion of your app on some other system image (machine or OS, we live in a virtualized world now) other than the client? If so, that sounds good. If not, I would not want all the over head of all those layers for an application on a Nokia tablet. I would guess that you would have so many pieces moving in that equation that playing music would suffer. I have to be honest with you, your intention of making a web frontend for Kagu seems a bit at odds with some of your stated funtions for the application: Kagu is a media player with a finger optimized UI with kinetic scrolling (aka inertial scrolling) written for Python 2.5 and greater. The finger optimized UI with kinetic scrolling is what drew me to your application. A web GUI would have neither of these features. It really sounds like you are wanting to take the application in a whole new direction , or maybe even totally change the nature of the application. If so, then maybe your client server vision for the application is no longer appropriate for the Nokia tablet (well, the client portion might be great if someone is near a fat network). Then you have to make sure that it will have 0% CPU residency, otherwise you'll be stealing playback time from your use-case. And you'll be taking memory no matter what, but hopefully not too much. Yes. I've already written Kagu using pygame. I've had to deal with CPU utilization and playback more than I'd like to admit. It would be significantly easier to handle without a GUI because I wouldn't have to worry about maintaining a consistent frame rate in pygame at the same time. Also, if you choose this approach, it is worth mentioning it in the release notes of your application, so that users
Re: web based local application GUIs
On 11/26/07, John Mitchell [EMAIL PROTECTED] wrote: Jesse, Not trying to throw stop energy into the mix, just reflecting on some of your points. You did ask for comments. So here are a few. :-) No, you're fine. I'm willing to explain my rationale. On 11/26/07, Jesse Guardiani [EMAIL PROTECTED] wrote: On 11/26/07, Igor Stoppa [EMAIL PROTECTED] wrote: On demand sounds great in theory, but let's think about it for a second: How do you start on-demand a web app? (HTTPD daemon) How do you play the next track when the current track finishes playing? (Kagu daemon, or FastCGI Kagu daemon + HTTPD daemon) Yes, that's the intrinsic problem of using an http-based approach. You rely on the http daemon being nice. You gain a lot from having an HTTP daemon though. You gain a consistent GUI (html + browser) and a common development methodology (web application development) that many programmers are already intimately familiar with. I would have to disagree on the consistency point. I spent three years doing n-tier database applications development with web based frontends, and getting a consistent look and feel (let alone functionality) across multiple OS/browser platforms can be _very_ difficult. Especially with all of the various security functions that users employ to protect themselves from nefarious scripts. In the end we gave up and targeted Windows only. I was very sad but we spent a _huge_ number of man hours trying to make it work. Sure. There are different frameworks and different languages and different browsers, but I do web dev for a living and I manage to make it work. It can be done, otherwise you wouldn't have a world wide web. And it's really not that difficult, IMO. You also gain the ability to use a high level language for GUI work while still having a very fast startup time (theoretically, I haven't tried it yet). While I agree with you for the majority of processors out there (1GHz or faster with lots of memory) the Nokia tablets are not so good in comparison at client side web application execution (think Web 2.0 or tons of JavaScript). Gmail with AJAX is pretty hard to use on my N800 (I have since given up), maybe it will be doable on my N810. I'm aware of this. I use GMail regularly on my n800 and it works fine so long as you turn off AJAX on the gmail end. I think appending ?ui=html to the URL does the trick. It *works* with AJAX. It's just too slow. Maybe that will change some day. But web applications don't need excessive javascript to function. They work just fine without it. You gain the ability to use CSS for application theming. You also gain portability. No more wondering why the strange PyGtk Hildonization hack you had to do back in Bora no longer works in Chinook. In fact, you no longer care if you're on chinook, bora, gregale, or the internet at large. It doesn't matter. All you need is a web server and a web browser and you're good to go. I have read that GTK portability is good, and in my limited experience was good across Windows, Linux, and Mac OS X. This is one of the reasons I have chosen it for the applications I am working on. Is the problem you are experiencing a function of the advanced interface work you are doing or is it truly a problem with the GTK/Hildon environment changing? Maybe with some other developers working on that problem the need for an n-tier application structure will go away? Perhaps. It's not just broken compatibility though, it's also startup time and portability. Both suffer on maemo currently when using a high level language like python. Not saying it can't be done, just that I don't really want to. python-launcher might change one aspect of this soon. And if python 2.5 ever shipped with the default OS, I might sing a different tune. But it doesn't. Kagu is used very similar to a daemon. It runs as long as you're playing music. And if that's all you use an n800 for then it's always running. It might even be in the background if you're taking notes or browsing the web. The difference is that it has a GUI right now. I'd like to make that portion optional to save some memory/CPU when you aren't using it. I'd also like to make startup time faster, and I'd like to make a web frontend for it. Do you intend on having the server portion of your app on some other system image (machine or OS, we live in a virtualized world now) other than the client? If so, that sounds good. If not, I would not want all the over head of all those layers for an application on a Nokia tablet. I would guess that you would have so many pieces moving in that equation that playing music would suffer. I think it can be done. And if the framework is there, then maybe other applications would use it too and we'd have a whole library of easy to develop/port/use web applications for maemo. I have to
Re: web based local application GUIs
On Mon 26 Nov 2007 22:16, Igor Stoppa [EMAIL PROTECTED] writes: Hi, On Mon, 2007-11-26 at 13:11 -0500, ext Jesse Guardiani wrote: [snip] This would mean that the Kagu backend process would be a daemon (aka a service, depending on your education environment). If possible, please no, not another daemon. We are already plagued by a large number of (mostly unnecessary!) daemons (i don't remember on top of my head how many exactly, but it's a 2 digits figure) that have trickled over the years in the standard stack. The metacrawler is a good example of why you don't want to write a daemon. To write a daemon is to ask for trouble since your sw will use memory, cpu time and power all the time. Also bugs will be more critical. In the beginning of this year (2007) I wrote a tool called httpcmdd http://www.iki.fi/too/sw/httpcmdd/ which I planned to use another, perl based program on N770/N800. It is a persistently sleeping, standalone daemon which uses just a kilobyte or a few of (userspace) memory and does not do anything unless request comes in. The main reason I have not developed The Application for it is that Localhost Inet Socket Connections Does Not Work in Offline Mode! (with a close second lack of time). A small httpcmdd script could check whether a daemon for a particular purpose is running and if not, start it. Then it could redirect connection to the port of that daemon...if connections worked. In this case the connection refused problem I mention below exists. With the unix socket method I mention in httpcmdd web page and small modification in server code could fix even that problem. What's wrong with something that runs on-demand? A separate gui client which starts the server and browser on demand?...but LISCDNWiOM!! ;) and, when server exits after a (long) idle timeout browser just gets connection refused -messages... if browser could be made able to launch such a server in this case that would be nice... Unless you rely on having dbus to start and stop the service ... that would probably be ok. Any good solution for running http-based applications offline and on-demand (user just using browser bookmarks) on these Internet Tablets would be nice. Maybe there is enough interest to make this happen ? -- Cheers, Igor Tomi Igor Stoppa [EMAIL PROTECTED] (Nokia Multimedia - CP - OSSO / Helsinki, Finland) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers