You are not logged in.
One world: awesome!
Feel like new era of server side programming is coming ...
I think it is time SMS to make effort for client side mORMot compatibility.
Offline
I don't know but this ready to use SQL parser probably help you. http://jansfreeware.com/jansql.zip
SQL support is pretty uncomplete.
A newer fork is available in CodeTyphon, but still very rough and uncomplete (when compared to SQLite3).
Offline
Very first version of WebSocket server is available at google code: https://code.google.com/p/dwsockets/
It is based on Eric's http.sys 2 implementation, which on behalf implements mORMot http.sys server logic.
WebSocket Server uses abstract transport and is not dependent on the http.sys server implementation.
Can be used on the top of other transport (ex. custom tcp connection, pipes)
Windows 8 or Server 2012 is required (for Windows WebSocket Protocol API), and added library paths to mORMot and DWScript.
Precompiled WebSocket Echo Server is available in Downloads section along with simple html/javascript client.
Offline
This is just GREAT news!!
I've included it to the Feature request http://synopse.info/fossil/info/6f76571934
Thanks for sharing.
I'll take a look at your implementation.
I like very much your code, also the SRWLock use.
Why use an abstract class, and not just an interface, to be implemented optionally by the main HTTP Server class?
Offline
Thanks ab,
Like a lot slim read/write locks. From years I use them, introduced in Windows Vista and Server 2008.
Very fast multi read exclusive write. Only one drawback - one thread should not try to reacquire it.
Matter of code design, but think in web server worker threads it is not a big issue. Critical Sections are good, but read-locking a peace of data for all threads, like session data or user context is waste of resources, I think.
Why use an abstract class, and not just an interface, to be implemented optionally by the main HTTP Server class?
You mean usage of abstract class for WebSocket common API or transport abstraction?
I agree interfaces will be more suitable in both cases.
Tried to abstract the usage, further step can be to interface it.
Offline
Yes, already written the APIs, and simple implementation, but not ready to open the sources.
Will contribute them soon. Along with required websocket server test scenarios (using winhttp websocket* api as a client) and further fixes which will come after the tests
Offline
i am thinking about to use DWS within mORMot Framework.
in sample "HttpSys2WebServer", procedure "FDWS.HandleDWS" used TWebRequest and TWebResponse as parameters, but how to translate THttpServerRequest to TWebRequest in my server?
thanks.
Offline
I guess you try to use the mORMotHttpServer.pas server, then run DWS runtime within it.
AFAIK TWebRequest/TWebResponse are just some simple value related classes, and you would find every input and output information in THttpServerRequest.
Offline
i did, i used THttpServerRequest in my mORMotHttpServer server. but FDWS.HandleDWS should handle TWebRequest/TWebResponse parameters.
Offline
TWebRequest = class
private
FCookies : TStrings;
FQueryFields : TStrings;
FContentFields : TStrings;
FCustom : TObject;
protected
FPathInfo : String;
FQueryString : String;
function GetHeaders : TStrings; virtual; abstract;
function GetCookies : TStrings;
function GetQueryFields : TStrings;
function GetContentFields : TStrings;
function GetUserAgent : String;
function GetAuthentication : TWebRequestAuthentication; virtual;
function GetAuthenticatedUser : String; virtual;
function PrepareCookies : TStrings; virtual;
function PrepareQueryFields : TStrings; virtual;
function PrepareContentFields : TStrings; virtual;
public
constructor Create;
destructor Destroy; override;
procedure ResetCookies; inline;
procedure ResetQueryFields; inline;
procedure ResetContentFields; inline;
procedure ResetFields; inline;
function Header(const headerName : String) : String;
function RemoteIP : String; virtual; abstract;
function RawURL : RawByteString; virtual; abstract;
function URL : String; virtual; abstract;
function Method : String; virtual; abstract;
function MethodVerb : TWebRequestMethodVerb; virtual; abstract;
function Security : String; virtual;
function ContentData : RawByteString; virtual; abstract;
function ContentType : RawByteString; virtual; abstract;
property PathInfo : String read FPathInfo write FPathInfo;
property QueryString : String read FQueryString write FQueryString;
property UserAgent : String read GetUserAgent;
property Headers : TStrings read GetHeaders;
property Cookies : TStrings read GetCookies;
property QueryFields : TStrings read GetQueryFields;
property ContentFields : TStrings read GetContentFields;
function HasQueryField(const name : String) : Boolean;
function HasContentField(const name : String) : Boolean;
function IfModifiedSince : TDateTime;
property Authentication : TWebRequestAuthentication read GetAuthentication;
property AuthenticatedUser : String read GetAuthenticatedUser;
// custom object field, freed with the request
property Custom : TObject read FCustom write FCustom;
end;
TWebRequest above is defined in dwsWebEnvironment.pas of DWS package, i can create an instanc as follow:
WebRequest := TWebRequest.create;
and how could i assign the value to WebRequest.RemoteIP...?
Offline
Offline
sorry for my english,ab.
i know how to get remoteip from CallContext, but don't know how to assign it to TWebRequest.
Offline
ab, Could you include TWebRequest item in THttpServerRequest?
Offline
I would not like mix the two concerns...
DWS and mORMot are diverse projects, with diverse targets.
Including DWS units within mORMot would break a lot - including support of older compilers, cross-platform compilation, FPC support, etc...
So I would definitively not include TWebRequest in the main mORMot trunk.
What we may do is create a new unit, which would be able either:
- To use a mORMot server within the DWS http server;
- To use the DWS engine within a mORMot server.
I guess that the 2nd option may be preferred (e.g. to be able to use WebSockets, whereas the DWS http server do not support them).
But honestly I've no time for it now.
I would help fixing your integration, if you (or someone else) start this work.
Offline
The 2nd option would be preferred, and I would like to get started with it.
I planned to script it in the onrequest procedure of mORMot server, or should I use the WebSocket?
Many thanks.
Offline
The OnRequest event of the mORMot server will work with all the framework HTTP servers: http.sys, sockets, and websockets.
So if we manage to run DWS scripts from this event, via the THttpServerRequest class instance generated by the HTTP servers, we are good!
Offline
That is what I did.
DWS has a sample "HttpSys2WebServer", it used TWebRequest/TWebResponse parameters for FDWS.HandleDWS procedure, that is why I asked you how to prepare TWebRequest from THttpServerRequest.
It will be great if THttpServerRequest provides the TWebRequest information.
Last edited by profh (2015-04-07 22:41:40)
Offline