I just wanted to post an update on 2.07 and the progress that's being made.  I'm a bit behind at this point, so things aren't going to be done by the first part of August.  But, the SSL/crypto support is almost done, and that's the really difficult portion of 2.07.

In case you're not aware, as of right now 2.07 will have:

- SSL/TLS and better crypto/hashing support (uses Windows Crypto API, so no external DLLs required)

- GZip support

- Support for server-side EWB applications, including built-in session management, user/role management, database/dataset management, file management, etc.  You will create server-side applications in the IDE just like you create browser applications, only instead of forms you'll have modules that can perform routing/request handling.  All of the built-in web server functionality will be accessible as classes/functions/procedures, just like it the browser native APIs are accessible with EWB browser applications.

- Web UI and server-side application (EWB, of course) for remote administration (source included)

The only thing that I wanted to include, but won't be able to, is multi-domain/multi-tenancy support in the EWB Web Server.  This probably won't ever see the light of day, and will be used internally when we start providing hosting here for EWB applications.

Also, debugger support is planned, but won't make it into the first iteration of the server-side applications.  Eventually, you'll be able to debug both client-side and server-side applications in the IDE.

Tim Young
Elevate Software
www.elevatesoft.com

Simply stunning. Really can't wait for the server-side capabilities. Roll on my next project and thanks, as ever, for the endless innovation.

This is amazing stuff Tim.  Like Mark I can't wait for the server-side functionality.

= Steve

Uli suggested that I explain the server-side applications a bit more, and I agree, so...

Currently with the EWB Web Server you have to use Delphi to create native web server modules if you want to provide server-side functionality. There's absolutely nothing wrong with this, and it's a great way to re-use non-UI code from desktop applications that are being ported to the web.  Plus, it's the best performance one can get.  This model won't be going away, although it will be seeing some changes, specifically in how databases/datasets are handled.  The primary issue with Delphi for a lot of new EWB customers that *don't* use Delphi is the licensing cost.  The server-side applications implementation is a way to ease this burden.  Most of the time, developers don't have any problem with using Object Pascal, and they would have no problem with the Delphi license costs if they were *also* creating desktop applications.  Rather, they have a hard time justifying the purchase of a Delphi license for simply building one or two EWB Web Server modules.

The server-side applications are *not* native code and are interpreted.  However, most of the built-in functionality *is* native code, so only a small part of the codebase (your application code) will be using the EWB server-side run-time. As mentioned before, the server-side applications will be able to access a *lot* of built-in, native functionality such as session handling, user/role administration, database/dataset administration, crypto (hashing, certificate management, encryption), email, HTTP calls, etc.  This means that you will not need to do very much to handle most of your server-side needs. So, performance will be good, but not as good as native.  The run-time is the same one that you've been using in the IDE at design-time since 2015, so if you haven't noticed any slowness, then you definitely won't notice any slowness on the server-side.

The server-side applications will be developed/compiled/deployed in the IDE just like EWB browser applications.  They are monolithic (single file with a .wba extension), meaning that they will contain all necessary dependencies and won't be subject to "dependency hell" during deployment.  They will be *very* easy to update and not require a web server restart, and will (eventually) be able to be remotely debugged from the IDE.  They will also use the same Object Pascal implementation that the EWB browser applications use, so you will have a single-source solution.  When you create/open a server-side application in the IDE, the component palette/design-time environment will switch to reflect that you're using a server-side application, and the available components will also reflect this switch.  Instead of forms, you'll be creating non-visual modules and plain units.  The modules will allow you to drop components on them and create event handlers for request routing/handling (you can essentially route requests to various other modules, as necessary).  In general, you'll always have one main module, just like a main form, that may not do much, but provides routing for other areas of the application.

I hope that clarifies things a bit more. If you have any questions, please feel free to post them.

Tim Young
Elevate Software
www.elevatesoft.com

Tim,

/*
Currently with the EWB Web Server you have to use Delphi to create native web server modules if you want to provide server-side functionality. ...
*/

Does this mean that with EWB 2.07, I could say, write or import JS code from within EWB to generate a PDF file in response to a report printout request?

Is there anything that cannot be done (server-side) with EWB 2.07 that would still require Delphi to be used?

--
Frederick

On 8/8/2017 11:01 AM, Frederick Chin wrote:
>
> Does this mean that with EWB 2.07, I could say, write or import JS code from within EWB to generate a PDF file in response to a report printout request?
>

I'm not Tim so following are just guesses.

Assuming you have a pure non-visual JS library then possibly yes.

Note that this should work on EWB app today (client side) since JS
runtime is similar/same.

> Is there anything that cannot be done (server-side) with EWB 2.07 that would still require Delphi to be used?

As i understand this then this solution will be limited to what can be
done in JS code and calling EWB server built-in functions Tim mentioned.

Idea i believe is to cover majority of use cases for creating modules
today where the server side is just some code - think server side
processing.

There still still be special scenarios where delphi modules make sense
since those can in theory do almost anything.

I have no idea what Tim has planned for initial 2.07 but for example he
likely will not implement every protocol known to man just yet (say LDAP
or maybe some more special DB connection protocols and such) so for
those module would still be needed.

However, for most people, most of the time, the server side JS will be
all they need to implement their business logic.

Raul

Raul,

Thanks for your input.

I guess the real test will come when EWB 2.07 is released as there are no examples to look at at this time.

I would also like if EWB will be able to use Lazarus in the future as an alternative to Delphi.

--
Frederick

Raul wrote:

> following are just guesses.
>
> Assuming you have a pure non-visual JS library then possibly yes.

I may be wrong, but isn't the server going to run the "Web Builder Script", not the java output? That's what the IDE is doing I think. So this is not a javascript engine running, but a Pascal-derived engine.

I think this is going to be very powerful (it already is for the browser), but interacting with the external world will be required I suspect, using DLLs, and certainly the custom modules.

--

Matthew Jones

On 8/9/2017 4:37 AM, Matthew Jones wrote:
> I may be wrong, but isn't the server going to run the "Web Builder Script", not the java output? That's what the IDE is doing I think. So this is not a javascript engine running, but a Pascal-derived engine.

Interesting point - i assumed it's still javascript (not java - that is
whole other language). You write it in EWB pascal and it's transformed
and interpreted by JS engine.

No doubt Tim will clarify

> I think this is going to be very powerful (it already is for the browser), but interacting with the external world will be required I suspect, using DLLs, and certainly the custom modules.

Yes - agreed. The ewb web server itself will be a very powerful web
server at that point (you could use it even without EWB app on client
side in theory for some specific tasks).

Raul

Frederick,

<< Does this mean that with EWB 2.07, I could say, write or import JS code from within EWB to generate a PDF  file in response to a report printout request? >>

No, the server-side does not use JS at all.  It's an Object Pascal run-time that mirrors the EWB syntax that you use on the front-end.  You've essentially been using this run-time (at design-time in the IDE) since EWB 2.x was first released, so it's well-tested.

<< Is there anything that cannot be done (server-side) with EWB 2.07 that would still require Delphi to be used? >>

There will definitely be "holes" in the functionality to start, but over time these will get patched up.  That is also why the Delphi native web server module support isn't going away.

Tim Young
Elevate Software
www.elevatesoft.com