Hi,
Am Montag, den 02.01.2006, 20:06 +0100 schrieb dannym:
> Hi,
>
> Am Freitag, den 30.12.2005, 03:20 -0500 schrieb Lv:
> > I just tried it and it works very well!
> > Running on my web server already.
> >
> >
> > Now if only it would be possible to compile a Lazarus application to
> > make the GUI accessible through a browser.
> >
> > (I know it should rather be done with java, but who wants to learn new
> > languages all the time)
> >
> > Is there anything in the pipeline where applications written in lazarus
> > can be compiled for a browser GUI?
> > Meaning that the gui will appear within a browser and therefore web
> > accessible?
>
> ("compiled for a browser GUI" = "browser plugin"? "appear within a
> browser" = "be built into the browser frame like a toolbutton or label
> or something extending the page you are looking at"? "web accessible" =
> "be an actual web page that can be looked at with _any browser_"?)
>
> No, the web is radically different. Retrofitting a gui app onto a web
> page will suck. I've seen it, some people did it for a (huge) app in our
> company. (If you meant something like client side XUL, that is, writing
> a browser plugin/extension, then I misunderstood you - that is an
> entirely different matter)
>
> It's really hard to come up why this is so but it is.
>
> Maybe because on the web one expects to read pages, like in books, not
> see free-form GUI controls (like GUI forms are 80% air and web pages -
> ok, good ones - are 80% actual text information).
>
> Maybe it's because all the important GUI stuff doesn't work in the web -
> that is, although with your idea the application would _look_ like a gui
> application, it would not _work_ like one (i.e. no drag+drop, expanders,
> scrolling, multiple windows, quick response time, ...). That feels like
> the app is mocking you...
>
> Maybe it's because web pages are conceptually simple and _people like it
> that way_.
>
> Not sure.
>
> Also, there are (less important and easier to fix/workaround) technical
> reasons, like for example that cgis run on the server and usually one
> doesn't want the cgi to be called for every little thing - like on every
> character entered in an entry (text input box). If you want to avoid
> that, you have to separate the client and the server part and it becomes
> a client/server app. So it isn't your original simple GUI app anymore...
>
> Also note that most web stuff is transaction-based/sync-based and most
> gui stuff is not. er... that sounded weird... I mean:
> That is, a web page will download to your computer and stay there, not
> changing, you read it in all calmness and maybe you enter some data and
> when you are done, you submit it to the server. The server will sanity
> check it and merge your changes with the data that is on the server now
> (which is *not* neccessarily the same data that was on the server when
> you started reading). If there is a unsolvable conflict, it will tell
> you. Otherwise, it will do the merging for you.
>
> Gui stuff usually is nowhere near this kind of detachedness (in an ideal
> world, there is no reason why it shouldn't, but... ).
> Gui stuff usually does live-update. If a web page live-updates on me,
> I'll poke it (or worse, not even notice the change because it doesn't
> even occur to me that it could/should change on it's own accord).
>
> I'm sure there are more reasons but that are just the ones that came to
> mind right now..
oh yeah, "web applications" need to scale (because "web applications" -
and web sites - need to serve a lot of concurrent users). To scale it
needs to be stateless, that is, it has to transfer the state with the
request and reply, not keep it within the process (because the next
request from the same user goes to another webserver half across the
room and that one knows nothing about you)
cheers,
Danny
_________________________________________________________________
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
