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
