Hello Henry
Thanks for your input. Because I chosed Net/C# as my development
platform, it seemed for me at the first place that a C# port would bring
this Data Storage interopeability benefit to deveopers of standalone
desktop application. My app is an ETL (Extract Transform Load) utility,
that's why Apache MetaModel seems so worthy for me (and that's for long
that I waited for a versatile Data Storage solution).
The motivation is to develop a standalone ETL (Extract Transform Load)
desktop application which uses Apache MetaModel as a Data Storage API in
order to be get the interoperability benefit within the range of
available connectors.
Your advice to use gRPC (which is great, did'nt knew this solution in
fact) and the concern about maintaining another codebase are both very
pertinent. In that case, would it be a better idea to create a 'gRPC'
subproject ? My concern is that I would prefer a "Javaless" AND
"Serverless" solution but if Apache Metamodel with gRPC extension is
very straigthforward to deploy for a .Net standalone desktop app (and if
a server is required, that it is an "in process one") then your proposal
seems too make more sense than mine.
Last remark is that when progressing on this "C# port" prototype, I had
the feeling that C# is now a more modern language (less clumsy I mean)
than Java (IMHO, I may be completely wrong of course) and also maybe
that this prototype may reveal some "design / extensibility /
portability issues" in Apache MetaModel, especially because using a
programming language often bring its own set of biases because of the
design choices which are reified by its idioms.
Best Regards
Michel Kern
On 05-09-17 20:40, Henry Saputra wrote:
Looking at the initiative to port MetaModel to C#, I need to ask what is
the motivation to do this.
If it is just client bindings to be able to use Apache MetaModel in C#, or
other languages for that matter, we could use gRPC and move the interface
definition to declarative and allow code gen for different languages.
But rewrite the whole project into different language makes bit concern
about maintainability and effectiveness in long run.
- Henry
On Tue, Sep 5, 2017 at 3:38 AM, Dennis Du Krøger <
dennis.dukro...@humaninference.com> wrote:
I can take a look when I get home from work, but my C#/.NET experience is
ancient, last time I actively used it for anything must have been back in
the 2.0 days...
Oh well, a good chance to brush up a bit :)
BR,
Dennis
-----Original Message-----
From: Kasper Sørensen [mailto:i.am.kasper.soren...@gmail.com]
Sent: 5. september 2017 05:38
To: dev@metamodel.apache.org
Subject: Re: Port to C# (DotNet Core) 0.2.0 released and answers to
feedback
Hi Michel,
Thank you for the update on the project :-) I'm definately going to take
it for a spin shortly, but just super busy myself at the moment so I can't
react as quickly as I'd like.
If anyone else has any C# insights and can poke around a bit, I think that
would be very valuable!
Kasper
2017-08-31 0:36 GMT-07:00 Echopraxium <echoprax...@gmail.com>:
Hello Dev team
I've just released v 0.2.0 of a 'port to Csharp' prototype, here it is:
https://github.com/Echopraxium/apache_metamodel_dotnet_core_bud
Now the codebase is big enough (i.e. the 'engine' is ready) which
allows to run the unit tests (via 'MetaModel-cli-test' console app)
but still a lot of validation / debug pending (e.g. in
JsonDataContextTest.testDocumentsOnEveryLineFile() only the first
Assert succeeds). Previously I sais that I applied a "brute force"
and "bottom up" approach. Now I would say that it's more the approach
seems more like porting a legacy codebase.
I agree with Kasper that a rewrite with CSharp strengths and
weaknesses makes more sense than a "1 to 1 Force Fit". Beyond that
each language brings its own set of "design biases"
with the entropy/negentropy side effect of its idioms. Then my feeling
is that this prototype may hightlight the parts where such 'bias'
occured.
I just hope that this prototype may raise enough motivation to start a
"dotnet" child project within Apache MetaModel.
Best Regards
Michel Kern (echopraxium)
