mORMot Open Source

Right now, the text based record serialization is almost perfect for my needs except for these cases.  I really don't want to release my web service API with integers instead of named enumerations, as changing it later will cause customer confusion/problems (and it's not very readable).  I could revert back to using classes with the interface based services, but using records for DTO operations (as you suggested in another response) is certainly preferable.  Now that I have seen the record based functionality, I don't want to go back to using classes for my interface based services.

While Mormot is extremely powerful, fast, and obviously well thought out, IMHO it could benefit even more by introducing support for the newer RTTI features.  This would probably open doors for some easier coding styles in Mormot (e.g., generics, property and method attributes, etc.) and would probably increase the options for JSON serialization with classes too.  For those who have existing projects in versions < Delphi 2010, I can certainly understand that existing code should remain stable, however for new features I think it makes sense to consider support for newer language features.

Perhaps to make code maintenance easier, new units could be created that will encapsulate the new features without disrupting the existing code base and without littering the code with $IFDEFS, but I'm sure you have ideas on how to best address that.

In any case, taking one step at a time,  I would really like to see support for newer RTTI starting with text based record serialization.  How can I help to move this forward?

Thanks!

Here is a complete test program, but it still fails even after using M+ and descending from TPersistent.  I'm using Delphi XE 2 Update 4 Hotfix 1, along with the nightly Mormot build from April 20, 2014.

{$M+}
program JsonTest;

{$APPTYPE CONSOLE}

{$R *.res}

uses
  System.SysUtils, Classes, SynCommons, Mormot;

type
  TAddress = class(TPersistent)
  private
    FStreet: string;
    FCity: string;
    FZipCode: string;
    FCountry: string;
  published
    property Street: string read FStreet write FStreet;
    property City: string read FCity write FCity;
    property ZipCode: string read FZipCode write FZipCode;
    property Country: string read FCountry write FCountry;
  end;

  TContact = class(TPersistent)
  private
    FId: Integer;
    FFirstName: string;
    FLastName: string;
    FAddress: TAddress;
  public
    constructor Create;
    destructor Destroy; override;
  published
    property Id: Integer read FId write FId;
    property FirstName: string read FFirstName write FFirstName;
    property LastName: string read FLastName write FLastName;
    property Address: TAddress read FAddress write FAddress;
  end;

{ TContact }

constructor TContact.Create;
begin
  inherited;
  FAddress := TAddress.Create;
end;

destructor TContact.Destroy;
begin
  FAddress.Free;
  inherited;
end;

var
  C1, C2: TContact;
  Json: RawUTF8;
  JsonPtr: PUTF8Char;
  IsValidJson: Boolean;
  Ch: Char;
begin
  try
    TJSONSerializer.RegisterClassForJSON([TContact, TAddress]);
    // C1
    C1 := TContact.Create;
    C1.FirstName := 'Joe';
    C1.LastName := 'Smith';
    C1.Address.Street := '1234 Main St.';
    Json := ObjectToJson(C1, [woStoreClassName, woHumanReadable]);
    Writeln('=== C1 ===');
    Writeln(Json);
    C1.Free;
    Writeln;
    Writeln('Press ENTER to continue...');
    Readln;
    // C2
    JsonPtr := @Json[1];
    C2 := TContact(JSONToNewObject(JsonPtr, IsValidJson, [j2oIgnoreUnknownProperty]));
    Assert(IsValidJson);
    Writeln('=== C2 ===');
    Writeln(C2.FirstName);
    Writeln(C2.LastName);
    Writeln(C2.Address.Street);
    C2.Free;
    Writeln;
    Writeln('Press ENTER to continue...');
    Readln;
  except
    on E: Exception do
      Writeln(E.ClassName, ': ', E.Message);
  end;
end.

I have further questions:

How is this exception returned to the caller?  Is there a way to generate a specific exception to return the error to the caller in a JSON format as is provided with Ctxt.Error()?

It looks like both of these classes don't support standard REST URL behavior because they require the method names to be defined in either the body or the URL with the 'dot' notation.  Unfortunately, this won't work for me as I'm creating an API for other developers to access our system and I want the URLs to conform to the generally accepted standard REST URL format. 

If I override TSQLRestServerURIContext, how will that help me?  I'm not clear on what you mean by it won't be direct, unless you mean that the mapping between this class and the interface implementation won't be automatic.  If so, is there a way to manually create the mapping between the URL and the methods that get called (i.e., is there a way to gain control at the point of method dispatch so I can route the URL to the correct method?). 

Ideally, I'd like to map specific HTML verbs to specific method signatures and handle the parameters via the URL, like GET_Customer, POST_Customer, etc. or whatever convention I choose (I assume this is already being done somewhere in the code anyway). If I can override TSQLRestServerURIContext to create custom instance behavior, that would be great. If so, any example code (and/or which methods to override, etc.) would be greatly appreciated. 

Perhaps the only way to do this is by using method based services as you mentioned, but I'd prefer to use the interface based architecture if at all possible.

Just so I understand, sicPerThread means that on the server side, an instance of my service class that implements the methods will be created per thread in the pool.  If this is the case, then can I simply create a class variable within the service class that references my database connection for each instance.  If so, does the service class instance lifetime get managed in the BeginCurrentThread/EndCurrentThread methods?  I obviously don't want the threads to be terminated until my server application is shutdown, so I want to be sure that I understand the lifetime management of the instance.  Also, are there any limits with the thread pool or does it expand as needed?  Can I specify how many threads are initially in the pool?

Thanks again for the help!