Can I use the TSQLHttpClientWinSock in windows? how?

Roberto Schneiders · 2013-06-06 14:42:04

I can easily choose to use TSQLHttpClientWinSock instead of TSQLHttpClientWinHTTP?

I have some customers using our applications for windows on Linux with Wine. And is not working, I imagine the TSQLHttpClientWinSock solve it, but do not know how to use it.

I found this in SynCrtSock.pas:

{$ifdef MSWINDOWS}
  {$define USEWININET}
  /// define this to publish TWinINet / TWinHttp / TWinHttpAPI classes
{$else}
  {$undef USEWININET} // WinINet / WinHTTP / HttpAPI expect a Windows system
{$endif}

and this in mORMotHttpClient:

{$ifdef USEWININET}
  /// HTTP/1.1 RESTFUL JSON default mORMot Client class
  // - under Windows, map the TSQLHttpClientWinHTTP class 
  TSQLHttpClient = TSQLHttpClientWinHTTP;
{$else}
  /// HTTP/1.1 RESTFUL JSON deault mORMot Client class 
  // - not unders Windows, map the WinSock implementation class
  TSQLHttpClient = TSQLHttpClientWinSock;
{$endif}

But I do not want to change the framework. Especially, compilation directives.

Last edited by Roberto Schneiders (2013-06-06 14:42:41)

ab · 2013-06-06 18:03:02

You should directly use TSQLHttpClientWinSock instead of TSQLHttpClient, of course!

Roberto Schneiders · 2013-06-07 13:02:47

With Delphi XE2 and XE4 an error occurs when registering a service using TSQLHttpClientWinSock;

exception class : EServiceException
exception message : IControleEstacionamento interface or REST routing not supported by server:

Stacktrace:

0068ac07 +11f Project2.exe mORMot            32873 +14 TServiceFactoryClient.Create
0068431d +075 Project2.exe mORMot            29858  +6 TServiceContainer.AddInterface
006724e9 +05d Project2.exe mORMot            21723  +6 TSQLRestClientURI.ServiceRegister
0069593c +12c Project2.exe uClientMOrmothttp    59  +9 TClienteServidorSysmoEstacionamento.Conectar

works using TSQLHttpClient.

My interface:

  IControleEstacionamento = interface(IInvokable)
    ['{9D3E34D0-68D2-4095-9989-49021D89C2D0}']
    procedure CalcularDebitoTicket( ATicket: Int64; AOperador: Integer);
    procedure CalcularDescontoCupomFiscal(ATicket: Int64; ACupom, APDV: Integer;
      AData: TDateTime; AValor: Currency; AOperadorCaixa: Integer);
    procedure PagarTicketLiberarCancela( ATicket: Int64; AOperadorCaixa: Integer );
    procedure EstornarTicketEstacionamento( ATicket: Int64; AOperadorCaixa: Integer );
    procedure EstornarDescontoCupomFiscal(ATicket: Int64; APDV, ACupom, AOperador: Integer; AData: TDateTime; AEmCupomFiscal: Boolean = False);
    procedure LiberarTicketEstacionamentoSemPagar( ATicket: Int64; AOperadorCaixa: Integer );
    function GetEstadoPapel: RawUTF8;
    property EstadoPapel: RawUTF8 read GetEstadoPapel;
    function NotificarStatusPapel: Boolean;
    function RetornarDataHoraServidor: TDateTime;
    function PossuiFaixaDesconto: Boolean;
  end;

ab · 2013-06-10 15:08:18

I just forced the regression tests to define TSQLHttpClient = TSQLHttpClientWinSock and was not able to reproduce the problem with Delphi 7 (nor Delphi 2007).
But there was a problem when compiled with Delphi XE3.

In fact, this was already identified with the following ticket: http://synopse.info/fossil/tktview?name=11b327bd77

Delphi 2009+ fixed the internal text buffer to a size of 128 bytes, whereas we used a 1KB internal buffer.

Has been fixed by http://synopse.info/fossil/info/91cfffdaf8
(which also fixed Win64 execution problem)

Roberto Schneiders · 2013-06-10 19:31:23

Thank you Arnaud. I'll test.

ab · 2013-06-10 19:45:30

You are welcome.

I'm very interested for feedback about Wine compatibility of mORMot clients.
I do not see why it should not work as expected, unless we use some complex APIs.
We tried to maintain a low-level compatibility, even if high level API (like WinHTTP) are used.
For PDF generation and UI layout, GDI+ is needed. You can get the official DLL and put it in your Wine Windows folder, if the emulated version is not working as expected (it is not 100% complete AFAIK).

HK · 2013-06-17 17:42:46

Dear ab,

We are seriously considering to use your framework to implement a 3 tier architecture mobile POS solution. We are planning to use interface based services like the sample calculator application in directory no 14. I have the following question:
While processing a request initiated by a client the server might need more information from the client. What is the best way of implementing this? For example the client might request the server to insert an item into the customer order. While processing this request the server might realize that it needs more information about the item like for example the serial number of the item. I need a mechanism to have the server callback the client or inform the client that the serial number of the item is required. The client will then open a form to allow the user to enter the serial number and will send the serial number back to the server. The server will then complete the processing of the original request and will send the response back to the client. What is the best way of implementing this requirement?

ab · 2013-06-17 18:35:14

In a RESTful service over HTTP, there is no standard way of implementing "callbacks".
Even WebSockets are not fully supported in all environments (may be blocked by Corporate IT, for instance), and are a bit difficult to handle.

What you can do is use a sicClientDriven kind of interface based service:
"One object instance will be created in synchronization with the client-side lifetime of the corresponding interface: when the interface will be released on client (either when it comes out of scope or set to nil), it will be released on the server side - a numerical identifier will be transmitted with all JSON requests"
See http://blog.synopse.info/post/2012/03/07/Server-side

So your method can return an error code from server side, without loosing the execution context, then the client can react and add some information, update it then call back the original method.
When the client process will be finished on its side, its client interface will notify the server to release its execution context instance when it will be destroyed.

This is perfectly HTTP compatible, and easy to implement on both sides.

By the way, try to figure out how you may code it with RESTful WCF, and you will find out how mORMot can be a good option.

mORMot Open Source

#1 2013-06-06 14:42:04

Can I use the TSQLHttpClientWinSock in windows? how?

#2 2013-06-06 18:03:02

Re: Can I use the TSQLHttpClientWinSock in windows? how?

#3 2013-06-07 13:02:47

Re: Can I use the TSQLHttpClientWinSock in windows? how?

#4 2013-06-10 15:08:18

Re: Can I use the TSQLHttpClientWinSock in windows? how?

#5 2013-06-10 19:31:23

Re: Can I use the TSQLHttpClientWinSock in windows? how?

#6 2013-06-10 19:45:30

Re: Can I use the TSQLHttpClientWinSock in windows? how?

#7 2013-06-17 17:42:46

Re: Can I use the TSQLHttpClientWinSock in windows? how?

#8 2013-06-17 18:35:14

Re: Can I use the TSQLHttpClientWinSock in windows? how?

Board footer