[fpc-pascal] Servlet server for Fpc apps

[ritchie turner]

I'll chime in, I did a haxe servlet server called hxServlet, it's
available on libs.haxe.org. I'm thinking of doing something similar for
fpc. First, hxServlet is like ruby on rails mongrel, indeed it uses the
http header parser from mongrel, however it uses haXe's neko vm as the
server, and it's use is behind a proxy for delivering dynamic content as
it's not a full featured httpd.

Anyway, what I'm considering for fpc is wrapping jsapi, spidermonkey's
API, and link it into a pascal binary, which could contain a web server
for server side apps, and could just be a scripting language for desktop
apps. My focus tends to be web apps.

I think with spidermonkey now able to JIT and a server side JS API
movement taking shape, http://groups.google.com/group/serverjs, that
server side Javascript backed by a pascal runtime is quite a nice
combination. My goal would be to use RTTI to expose any pascal object as
a js global without pain and be able to create a servlet e.g. (off the
top of my head) ...


makeServlet(function(srv) {
 srv.url ="/servlets/helloworld";
 srv.doGet(function(headers)) {
   sqlite.query("select * from ...") ;
   print "hello world"
  })
})

It would be easy to decide which code should be written in JS and which
to be moved to Pascal for speed or plumbing, in this example, sqlite a
global JS object registered from fpc hopefully transparently. Maybe this
has been done already - for another language? - if so great !.

Regards, targeted and compiled javascript on the client, like gwt or
haxe (i did a haxe hxScriptlet similar to jquery), the problem is
debugging it, and using existing libs, you can, but it's painful, and my
takeaway from trying it, is it's not worth it, as you're fighting
against the tide. If you give it some time JS is actually very nice, and
with a tool like JSlint or a sophisticated editor like netbeans you can
remove most of the pain points. I would think the inclusion of tooling
for JS within lazarus, codetools for JS, would be a good (for me
anyway :)) - so that development could be done naturally from one place.

I'm fairly new to fpc and and object pascal, but I've decided that I'm
fed up with VMs, when I look at fpc I wonder where the huge advancements
in VMs are apart from complexity and memory consumption - i do make a
distinction with a VM in a scripting language, but for something I have
to compile anyway i'm not convinced of the wins.

Thanks for fpc, it's very pleasant to work with.

Cheers

bd

On Mon, 2009-03-30 at 21:16 +0200, Dariusz Mazur wrote:
> Adrian Veith pisze:
> > Dariusz Mazur schrieb:
> >   
> >> Marco van de Voort pisze:
> >>     
> >>> In our previous episode, Michael Van Canneyt said:
> >>>  
> >>>       
> >>>>> But maybe I dont understand your need.
> >>>>> You think about counterpart of LCL level, or computation wide
> >>>>> consist in event
> >>>>> (form.onclick, form.onedit) function in Delphi ?
> >>>>>       
> >>>>>           
> >>>> All events and almost any class I need should be available in the
> >>>> client...
> >>>>     
> >>>>         
> >>> Aren't you talking about two different classes? Webapps with some
> >>> browser
> >>> (Ajax) support, and more RIA-like JS apps?
> >>>
> >>> At least that is how it sounds to me, with Michael going more to the RIA
> >>> direction.
> >>>
> >>>   
> >>>       
> >> I don't talk about any compromise with appearance of application.
> >> Everything, as you imagine should be done with HTML+CSS.
> >> I dont think (I testing it every day) that is any bigger issue, that
> >> can't be done on server side with small JS addons on browser.
> >> RIA means for users beautiful, with 3D, alfa and animations efect. All
> >> can be done with small assistance of JS.
> >>     
> > That's the point - how do you define small ?!?
> >   
> As i mention before 1..2 kLOC all JS code for whole application. But it 
> doesn't matter. Most of them is universal,  as LCL.
> Is small as assembler inlines in most of applications.
> > If you can't do everything on the server, you have to perform some part
> > of the logic on the client. 
> Why any on logic move to client. I say only about GUI computation.
> > And the richer the client gets, the more
> > logic has to be performed on the client. Now you have the choice:
> >
> > 1. do the small part in JS - with the knowledge, that this part will
> > likely increase in the future
> > 2. or look for an alternative language, which is as close to what you
> > are used to program as possible
> >
> > My decision  is clear, after some hours hunting a bug, because i
> > declared a var "id" and somewhere made a test against "Id". I am using
> > the haxe to JS compiler, because its typesafe. If there were a pascal to
> > JS compiler, it would be an option to. But I doubt, that is feasible to
> > convert the libraries to work under that environment. And that's the
> > next problem. A language is only as good as its supporting libraries.
> >   
> I have the same point. Strong language is best choice for huge 
> application. I don't want to leave pascal, because it work: on desktop, 
> on web side, without imaginable limitation (performance, portables, 
> flexibility).
> Second: I don't want depend from users computer, name and version 
> browser, plugins. But if you move more code  to client side, then more 
> dependences you acquire.
> 
> And about HAXE. Its tool to write application for browser. For it seems 
> good. But I told about moving desktop, client-server, multiuser  
> application to web-based. Maybe HAXE in outline similar to FPC, but till 
> now hundred times smaller. Who trust this young and  unknown technology  
> and base huge application on it. And server side ? You can translate 
> client site to JS, server site to PHP, but what about communication 
> client-server.
> 
> 
> Darek
> 
> 
>