mORMot Open Source

I do hope we see each other at the EKON, I'll have a drink or two at the ready for you!

Okay, np.

In the end, it stops within the repeat loop:

function TThread.WaitFor: LongWord;
{$IF Defined(MSWINDOWS)}
var
  H: array[0..1] of THandle;
  WaitResult: Cardinal;
{$IF not Declared(System.Embedded)}
  Msg: TMsg;
{$ENDIF}
begin
  if FExternalThread then
    raise EThread.CreateRes(@SThreadExternalWait);
  H[0] := FHandle;
  if CurrentThread.ThreadID = MainThreadID then
  begin
{$IF not Declared(System.Embedded)}
    WaitResult := 0;
{$ENDIF}
    H[1] := SyncEvent;
    repeat
{$IF Defined(NEXTGEN) and Declared(System.Embedded)}
      WaitResult := WaitForMultipleObjects(2, @H, False, 1000);
{$ELSE}
      { This prevents a potential deadlock if the background thread
        does a SendMessage to the foreground thread }
      if WaitResult = WAIT_OBJECT_0 + 2 then
        PeekMessage(Msg, 0, 0, 0, PM_NOREMOVE);
      WaitResult := MsgWaitForMultipleObjects(2, H, False, 1000, QS_SENDMESSAGE);
{$ENDIF}
      CheckThreadError(WaitResult <> WAIT_FAILED);
      if WaitResult = WAIT_OBJECT_0 + 1 then
        CheckSynchronize;
    until WaitResult = WAIT_OBJECT_0;
  end else WaitForSingleObject(H[0], INFINITE);
  CheckThreadError(GetExitCodeThread(H[0], Result));
end;

MsgWaitForMultipleObjects(2, H, False, 1000, QS_SENDMESSAGE); always returns 258...

P.S.: Rather than an event handler, a virtual method should suffice, I'd guess.

Call it 2.0.0.x Alpha-Release and breaks are okay, until you come to the release, I would say ;-)

Okay, thx.

Still feels a bit funny, but I understand. Have a real problem now, will check a bit further and likely will open another thread in a minute.

Aye :-)

Ouch, but happens from time to time.

As long as SQLite stays supported, I think no one would ever be sad about a folder going away.

That certainly will be interessting, as we all have to start finding things again. But I hear you, those units are awfully big and likely hard to maintain. Certainly, giving you awesome JSON stuff its own realm to live in is a great step.

Not sure what the components would provide really, and likely would never use them, but I think almost no one is using everything of the framework, so they would not hurt. Just can't really see the benefit of those. Then again, I promote using web interfaces, which would not need them anyways.

Not using FPC, but gladly keep testing on D10.3 and coming versions. As you use FPC for your work since a few years, I am sure, it's been your focus anyways, so getting rid of a couple old versions should be fine, I'd say.

And as your documentation is better than almost any other out there, I am not scared of the coming changes.

Regards,
Daniel

P.S.: Do you have a time frame on that?

Have tested it and it works. Now I'll have to extend it for our scenario.

I would be happy to try to implement HTTP/HTTPS relay. However, do you have a pointer, as to what could be the most performant way?

Thanks,
Daniel

I just used that as a simplified sample. The real world problem we have is way more complex and as we just have to "run" after federal changes every quarter of the year, and have to be backwards compatible with older requirements for at least a year, I was looking for something easier.

What we really need, are changed implementations, as the services of the other parties change every so often, however, I would like to keep the client unaware of that. The "tax sample" was really a totally over-simplified sample.
The client shall simply say, I need to generate the tally for a certain period and submit it. Depending on the period, we have to implement totally different algorithms. And this is only one of many areas that change quarterly, therefore an abstract factory, that is returning the correct implementation would be best.  Honestly, I can't see how that would break the Liskov substitution principle, quite contrary to that. It is using it. I just don't want the client t decide which derived implementations of each service to use, but let the server decide which child class would be the correct one.

Worked with prior releases (from about a week ago), just pulled the most recent updates from GIT and it's not working as expected.

Any hints, anyone?

Oh yes, it will. May it be, that you forgot to commit sample 38, you mentioned it in the comments, but it does not show in the rep.

Thx

Oh yeah, it will be and I am not sure we would like to do it. But for now, this is a small research project, so I am fine with this.

Hi Arnaud,

right now I cannot see, how this would solve the problem. Let me try to explain in other words.

Simple work model is easy. Client App (possibly a web interface, possibly a GUI client) connects to the mORMot server, as just about any of the demo apps to demonstrate. Easy, no problem.

The mORMot server is the *only* server having direct access to the data, no replication involved. Now, for various reasons and restraints, when out of office, the client app needs to access the server. The client cannot use a VPN, nor connect to the mORMot server directly. There is simply no way inbound connections into the server are available. Outbound are though. Think of it, like TeamViewer can map sessions around most firewalls, by providing an HTTPS server to route all traffic.

When running the mORMot server will connect with our HTTPS server and announce, that it is available.
When being out of office, the users client will connect to an HTTPS server provided by us, identify and get the correct destination server assigned.
From here on all requests made by the client are sent to our HTTPS server and this one must forward it to the correct mORMot server.
The real problem for me is, that mORMot usually receives request via POST/GET/DELETE/..., however, as there are no inbound connections allowed, the server has to pick up those requests (HTTP GET) and unwrap the original request and process it as it would, when the client connects directly.

So my question here would be, do you have an idea where best to hook into the framework to make that work. Yes, the process would be slower, than connecting directly, however, as of now, we do not see a better approach. However, a better approach is just as welcome. However, we must keep in mind, while data must be transfered, the database must not be replicated.

Yes, but many customers here do not like the burden of a VPN setup and rather look for another, for them, simple solution. VPN was my first though too, but this is considered undesirable here.

Hello Arnaud,

thx for your service, this fixed it for me too.

Kind regards,
Daniel

Well, as I said, I did not get very far. From

function TSQLDBStatement.FetchAllToJSON(JSON: TStream; Expanded: boolean;
  RewindToFirst: boolean): PtrInt;

...
    while Step(RewindToFirst) do begin

it goes into

function TSQLDBSQLite3Statement.Step(SeekFirst: boolean): boolean;
...
    result := fStatement.Step=SQLITE_ROW;

to

function TSQLRequest.Step: integer;
...
    result := sqlite3_check(RequestDB,sqlite3.step(Request),'Step');

Which seems to be a function within the SQLite driver. (sqlite3.step(Request))

Then it jumps into

function memset(P: Pointer; B: Integer; count: Integer): pointer; cdecl; { always cdecl }
// a fast full pascal version of the standard C library function
begin
  FillCharFast(P^, count, B);
  result := P;
end;

and upon return into the CPU view... :-(

Regards,
Daniel