You are not logged in.
Pages: 1
I know that I can fork, but first I should try to help here.
> What is wrong with using SynCommons?
There is nothing wrong with SynCommons. As I listed in my other posts, add the dependency 29753 lines of code for a few types is something that I would evaluate better, since Windows Service can be used for any other type of project, not only mORMot.
I have about 8 different types of Windows Services here, half of that has no need for any Database, ORM, PDF or log, 2 is only for hardware interface.
> SynLog
I think that change the design to inject the log is a design improvement and you can still inject using SynLog.
Here we use Windows EventLog for Windows Services, there is no need to duplicate the log implementation, and our solution works fine for Log Files, Windows EventLog, Remote log and Debug.
Change the design will allow one to keep synLog or integrate to any existing solution.
> We now use mORMotService.pas as part of dddInfraApps.pas, which is a full featured cross platform process to
> build Windows Services or Linux Daemons, including settings, logs, console output, Windows Service installation (in a single executable).
So the aim is use mORMotService only with "full featured cross platform process to build Windows Services", it should not be used with any other kind of existing projects?
I'll post here first, just to see what you think about my proposal. if we agree about that, Ill post it as a feature request.
Yesterday I was evaluating mORMotService and tested it with a existing project, what I liked is that it has all the essential code that one need to implement a windows service, what I dont liked is that depends on SynCommons and SynLog.
I have a existing project and now I want only mORMotService, my project already has Log Service. The types and methods used from SynCommons is too little for a big unit that will not be used elsewhere in my project.
So I'm wondering if mORMotService can be a independent unit to be used in any project. I made the changes myself just to test, and here is what I have changed:
From SynCommons:
type
RawUTF8 = string;
SynUnicode = string;
PtrUInt = NativeUInt;
PPtrUInt = ^PtrUInt;
PtrInt = NativeInt;
PPtrInt = ^PtrInt;
ESynException = class(Exception);
I think ESynException should be a EService inside mORMotService.pas
methods
- StringToUTF8
- StringToSynUnicode
- ExeVersion.ProgramFileName to ParamStr(0)
- GetEnumName use it direct from TypInfo unit
units removed from interface uses : SynCommons, SynLog
units added to implementation uses: TypInfo;
So far, only simple things is used from synCommons that can be inside mORMotSerice.pas
Log:
And the Log part should be implemented by Dependency Injection (no Container needed), the actual implementation add the dependency to SynLog, and that is not good design IMHO. One could be allowed to use other log implementation.
A simple solution can be just a log event var instead of ServiceLog: TSynLogClass, and add a Log method in TService that will check if the log is assigned only in one pace.
Regards,
Cesar Romero
Pages: 1