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 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).
Kinetic scrolling is nice. True. But the browser already has tap and drag
scrolling.
That's pretty close to kinetic scrolling. Who knows, maybe having more apps
that
use the browser would force Nokia to devote more resources to browser
development,
making the browser faster, easier to use, and less buggy.
Then we'd all benefit, and maemo would have one killer application to rule
them all.
> > 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?
No, I'm still interested in finger driven UI. But the browser offers that
today. It's not
as polished as I'd like, but perhaps if we use it more it'll become more
polished.
I like maemo's browser. I think it's really really impressive. And I think
it can become
even more impressive with time. It's an infrastructure decision.
--
Jesse Guardiani
Software Developer / Sys Admin
[EMAIL PROTECTED]
_______________________________________________
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
