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 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.
>
>
So maybe in the end your drive for an n-tier structure is not one
born out of pain from GTK/Hildon, but out of a desire for different
functionality than the current finger driven GUI focus?
>
>
> --
> Jesse Guardiani
> Software Developer / Sys Admin
> [EMAIL PROTECTED]
> _______________________________________________
> maemo-developers mailing list
> maemo-developers@maemo.org
> https://lists.maemo.org/mailman/listinfo/maemo-developers
>
>
--
John P. Mitchell <[EMAIL PROTECTED]>
_______________________________________________
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
