mORMot Open Source

Hmm, I didn't realise there would be an issue in moving it to run in firemonkey on iOS - I guess that since I'm only using the client/server interface with encryption and object serialisation I ought now move to my own implementation of these as you suggest using Indy, and object serialisation and a standard encryption mechanism.
As I'll never need to share objects with other clients using this interface, I think I'll avoid JSON and just use Delphi's serialisation of a TPersistent if I find that portable between VCL and FMX.
I've found your server processes to be very reliable so I hope my Indy servers will be as stable!
I've found your architecture to be very simple and clean so hopefully I can continue in the same vein.
Thanks for all the great code.
Paul

I can't take the latest version from Fossil - this goes live next week and there would be too much regression testing to change the underlying code at this stage! However our posts crossed - I have this working for me now.

If I ever make any money out of this project, how can I remunerate you for this very useful software you provide?

Hi Arnaud, that is not working for me.

My Server code is:
        aServer.ServiceRegister(TServiceERefServer,[TypeInfo(IERefServerInterface)],sicShared).ContractExpected := CONTRACT_NAME;

My Server appears to be starting fine but when I call the following client method:
      FClient.ServiceRegister([TypeInfo(IERefServerInterface)],sicShared,CONTRACT_NAME);

It goes into the following and fails by raising the exception at the bottom of the code segment:
constructor TServiceFactoryClient.Create(aRest: TSQLRest;
  aInterface: PTypeInfo; aInstanceCreation: TServiceInstanceImplementation;
  const aContractExpected: RawUTF8);
var i, siz: integer;
    P: PCardinal;
    Error, RemoteContract: RawUTF8;
begin
  // extract RTTI from the interface
  if not aRest.InheritsFrom(TSQLRestClientURI) then
    EServiceException.CreateFmt('%s interface needs a Client connection',
      [aInterface^.Name]);
  inherited Create(aRest,aInterface,aInstanceCreation);
  // check if this interface is supported on the server
  if aContractExpected<>'' then
    fContractExpected := aContractExpected; // override default contract
  if not CallClient(SERVICE_PSEUDO_METHOD[imContract],@Error,'',@RemoteContract) then
    raise EServiceException.CreateFmt('"%s" interface or %s routing not supported by server%s',
      [fInterfaceURI,GetEnumNameTrimed(TypeInfo(TServiceRoutingMode),fRest.ServicesRouting),Error]);

The error message is:
'"ERefServerInterface" interface or REST routing not supported by server'

I suspect the problem is with the server because if I invoke the original call on the server:
        aServer.ServiceRegister(TServiceERefServer,[TypeInfo(IERefServerInterface)],sicShared);

Then it correctly reports that the contracts are different when I make the client call passing my constant as the ExpectedContract.

Any ideas?

Paul

Arnaud, I have been able to add the ContractExpected parameter on the client side but I can't see how to specify it on the server side?

My server side is:

  aModel := TSQLModel.Create([],ROOT_NAME);
  try
    aServer := TSQLRestServerFullMemory.Create(aModel,FILE_NAME,false,true);
    try
      aServer.ServiceRegister(TServiceERefServer,[TypeInfo(IERefServerInterface)],sicShared);
      aHTTPServer := TSQLite3HttpServer.Create(COMMS_PORT,[aServer]);

How do I specify the ContractExpected on the server side?

Paul

Hi Arnaud, thanks for the quick response.

That is great news that I can provide an optional parameter to override this default behaviour. I just want to double-check - I never want a client to get a rejection from a server as the server should always be backwards compatible so does that mean that I should just hard code a static value into that optional parameter and never change it? If I used a version number, I would have thought that when I update the version number of the server that any clients calling passing a different value in that optional parameter would fail is it does now if the interface is updated?

Also, I would like it if the server could support a test and production version of the interface concurrently. Can I configure a single service to support two interfaces concurrently or have two services running alongside each other on same IP and port but responding to different interfaces?

Regards

Paul

Arnaud, I couldn't see anything obvious but it is taking too long to try and resolve the issue so I've applied the additional code you'd added for passing the proxy settings into the old code base that I have and that is working for me now. It just means that I'm isolated with the old code base but it is working fine so I'm not too perturbed by that just now.
Thanks for the assistance as ever. At some point I'll try again to find what's causing it not to work...

Arnaud, I double-checked and is failing with the latest version and latest .obj files and building both client and server.
If I change the path to the original Synopse folder and recompile both they work fine.
Any other ideas of how I can find the issue?
Thanks
Paul

P.S. This is the code I'm using to connect which causes the code to fail:

procedure TClientToServer.doConnect;
var
  I:  IERefServerInterface;
begin
  // Run procedure to get the proxy info into FProxyInfo
  extractProxyInfo;

  if FClient=nil then begin
    if FModel=nil then
      FModel := TSQLModel.Create([],ROOT_NAME);
    FClient := TSQLite3HttpClient.Create(SERVER_IP,COMMS_PORT,FModel,false,FProxyInfo.ProxyURL,FProxyInfo.ProxyBypass);
    FClient.SetUser(MOR_USER,MOR_PASS);
    try
      FClient.ServiceRegister([TypeInfo(IERefServerInterface)],sicShared);
    except
      on e: exception do
        logmsg('Error in TClientToServer.doConnect: '+e.message);
    end;
  end;
  if FClient.Services['ERefServerInterface'].Get(I) then
  begin
    FMainInterface := I;
  end;
end;

I reverted to the older version of the Mormot code and it runs just fine so this is some incompatibility that has been introduced

Paul

Hi Arnaud, that's great, I'll get the latest version and try it out - it's just what I need.
Regards
Paul

Hi Arnaud, I can't just pass the silo variable as a TCollection as you'd said above that I would need to subclass it and add methods for adding TCollectionItem subclasses to the collection. That's just too much work for all the types of containers I need to pass across and I don't really understand why Mormot requires this when the serialisation/deserialisation of TCollections works just fine.

I'd not come across RawByteString but when I tried to define an interface between the client and server with a RawByteString parameter it causes the server to crash immediately on startup. I don't have time to investigate why.

I'm finding performance to be acceptable so it is not a problem for me to base64 encode/decode it if it makes it work as it does but it would be great if you can find and fix the bug to avoid me having to!

Paul

Hi Arnaud, I have another issue.

When I call a function on the server and pass back a string, if the string is 2460657 characters it returns okay but as soon as I try and return a string with 2461055 characters I get an error raised:
'Error calling ERefServerInterface.getSiloData remote method'.

The function has following structure:
    function getSiloData(const userId: RawUTF8; var inSiloS: RawUTF8): integer;

There must be some limitation on the inSiloS string length? I'm using it to encode my collection of objects using "ObjectToJSON" which is quite happy returning strings 20M characters. How do I overcome this issue to use the client/server calls to return longer strings?

Paul

Hi, but I'm testing it with the n2 parameter having been created with the TCollTest and just trying to invoke the call from client to server causes the error even without trying to add items on the server side.
The same error occurs if I pass a dynamic array - even if I don't try and manipulate the array on the server side.
I can use the ObjectToJSON/JSONToObject but it can't be anything too tricky to resolve as all I'd imaging you're doing here is using those methods to serialise and deserialise the parameters before passing the data across the HTTP connection?
Anyway, I'm not stuck but let me know if you have a workaround for the issue I can use.
Thanks
Paul

Hi Arnaud, in Delphi you don't need to subclass from TCollection and implement Add and Item methods to work with collections - just passing the TCollectionItem subclass to the Create method of TCollection allows it to add items of the correct subclass when you invoke the Add method on TCollection.
I'm happy to do it your way if that is what is required to make it work with mormot but it is not the standard way. The article you reference subclasses TCollection (THairs) as a convenience so that the Add and Item methods return the correct subclass but they are NOT mandatory to allow TCollection to work and the code I sent you just using a plain TCollection is correctly instantiating the correct subclass when you invoke its Add method.
I shall use this now on the assumption that you've tested this and it works. However, I also got a pretty similar error when using your recommended approach with records and dynamic arrays - it might be useful for anyone who does prefer records/arrays to know how to make that work correctly?
Thanks again for the prompt responses - great support.
Paul

Hi Arnaud, I need to use HTTPS rather than HTTP for the communication between client and server - do you have a reference of how I configure that?
Paul

BTW, have you used live bindings for linking user interface controls to objects?
I'm using bidirectional bindings with a few helper methods that allow me to map object fields to controls like the following and hey presto I have a UI and object kept in sync:

procedure TfrmNewReferral.doBindings;
begin
  // Create a binding expression.
  bindTogether(self, bsPatient, 'FirstName', aePatientFirstName);
  bindTogether(self, bsPatient, 'Surname', aePatientSurname);
  bindTogetherPopulateCombo(self, bsPatient, 'Title', cbPatientTitle, TPersonTitle);
  bindTogether(self, bsPatient, 'Gender', cbPatientGender);
  cbPatientGender.Items.Text := TGender.combolist;
  bindTogether(self, bsPatient, 'Marital', cbPatientMaritalStatus);
  cbPatientMaritalStatus.Items.Text := TMaritalStatus.combolist;
  bindTogether(self, bsPatient, 'Dob', dpPatientDOB, 'Date');
  bindTogether(self, bsPatient, 'HomePhone', mePatientHomePhone);
  bindTogether(self, bsPatient, 'MobilePhone', mePatientMobilePhone);
  bindTogether(self, bsPatient, 'Email', aePatientEmail);
  bindTogether(self, bsPatient, 'NhsNumber', mePatientNHS);
  bindTogether(self, bsPatient, 'Postcode', aePatientPostcode);
  bindTogether(self, bsPatient, 'Address1', aePatientAddress1);
  bindTogether(self, bsPatient, 'Address2', aePatientAddress2);
  bindTogether(self, bsPatient, 'Town', aePatientTown);
  bindTogetherPopulateCombo(self, bsPatient, 'County', cbPatientCounty, TCounty);
  bindTogetherPopulateCombo(self, bsPatient, 'Country', cbPatientCountry, TCountry);
end;

Hi Arnaud, okay, that is fine - thanks for the help - it is working now.

The other pattern that I have is that I want to have the client request the server for a collection of patients. Which is the best mormot calling structure to have the server return a collection/array/list of patient objects back?

for example:

procedure TServiceCalculator.GetMalePatients( forRegion: integer; out patientList: TList);

or perhaps:

function TServiceCalculator.GetMalePatients( forRegion: integer ): TList;

Paul

Hi Arnaud, when I tried to use effectively:

function TServiceCalculator.TP(var n1: TPatient; var n2: TPatient): integer;

or

function TServiceCalculator.TP(out n1: TPatient; out n2: TPatient): integer;

I get the following error raised from your code:
Invalid "Calculator" interface call: returned object.

And besides, an object parameter is a pointer to a pointer so it should be superfluous to declare an object parameter as var as if you want to change the object instance you change what the outer pointer points to.

I'm running the latest version of the code like you told me to. Do you want me to email you a version of the sample 14 project that is broken so you can see this first hand? If you email me paul @ westsw.com I can email you back the simple code... This is a very basic and simple requirement so it must have been implemented? I can serialise the object as a string myself and pass it that way if needed but I'm sure that is unnecessary???

Paul

The code that raises the exception is:

function TInterfacedObjectFake.FakeCall(var aCall: TFakeCallStack): Int64;

    if ValueDirection in [smdVar,smdOut,smdResult] then begin
      V := Value[a];
      case ValueType of
      smvObject: begin
        R := JSONToObject(V^,R,valid);
        if not valid then
          RaiseError('returned object');
        IgnoreComma(R);
      end;

(AB note: I edited your question since we do not need the whole framework code here - just he name of the method is enough)

Hi Arnaud, I'm trying to test the framework as you described just using interface-based services.
I looked at the sample code for project 14 but it is too simplistic just invoking an Add method returning an integer.
I want to test this passing objects in both directions. I don't need the ORM as you identified, so what sample code can I see to simply demonstrate passing an object from client to server and a call from client requesting objects to be sent back?
If I can quickly get a simple example that works I'd be delighted to use the framework.
Thanks in advance.
Paul