Poll: Functionally Equivalent or Direct Syntax Port?

Coordinator
May 27, 2010 at 10:41 PM

All, 

I'd like to get some community feedback about the direction of the project. 

 

After getting into the code a little, it's clear to me that the syntax and style of the original C++ SDK is very C++ idiomatic. It takes advantage of the very powerful features of templates to ease code readability, future proof for easy changes, and reduce code repetition. 

Unfortunately, that doesn't mesh so well with C#, as it lacks those kinds of features. 

My original intention was to port this as directly as possible, doing a "syntax port" as opposed to re-writing it. This has led to a certain amount of ugliness in the C# code. There are ways to get functionally equivalent code in C#, which are much more readable, but would require a departure from the C++ structure. 

The advantages of a syntax port is that, as the C++ SDK project continues and improves, merging those changes into the C# project will be much easier if there is a near 1 to 1 mapping between the two codebases. The farther I depart from the C++ code, the more conceptual overhead there will be when updating the project to match the C++ code improvements. This could prove to be a significant barrier towards maintenance.

 

Would better looking C# code that was functionally equivalent be preferred to a more direct syntax port approach? If so, I'll switch gears now. 

 

Looking forward to your feedback.

 

Thanks,
Troy

 

Jun 1, 2010 at 4:19 PM

Troy -

I'm pretty interested in the PST parser and think that having it available in .NET would be great.   I'd think that a great first step might be just a wrapper of the C++ version (boost dependencies and all).     You could indirectly expose the C++ managed wrapper through C#, then as time goes by you could expose additional functionality through C#.   For instance one piece of functionality that would be nice would be the ability to export a e-mail message to .MSG.      Just my 2 cents.

 

 

   

 

Coordinator
Jun 1, 2010 at 7:46 PM

NovaP, 

The idea of compiling and working with the C++ SDK using MC++ is quite practical and something I initially considered. This would be a great way to get up and running in a .NET environment right away, allowing an end user to access the PST structure and start working on the higher level abstractions and functionality such as export code.

I definitely suggest pursuing this route as a means of getting up and running as a user in a .NET environment. 

I may even spend some time working on a how-to document for doing that, and provide a VC++ project and some code to that end. This would primarily be done to facilitate end users who are eager to get started right away.

That said, providing access to the PST structure to .NET developers is only part of this project's goals. One of the big goals in my mind, is that the code is entirely C#. I really want to see this run on Mono, or anywhere 2.0 C# code is understood. I also want to see this ported to Java and Python.

I also want to see the storage layer be abstracted so that it could be implemented in a variety of ways, not just "disk based". I'd like to see the structure be able to live on top of a SQL database, or function completely in memory, or work with another kind of distributed storage that doesn't use typical file metaphors. This comes from my experience with the Lucene search/index engine, and it's underlying design and architectural principals, and how those have served to make it very flexible in a lot of different scenarios. 

The more I think about how to implement the ported code, the more I realize that those goals are very important. I think I've answered my own question now. I'm going to focus on implementing this in the way that makes the most sense in C#, even if it means a significant divergence from the C++ code. 

Thanks,
Troy

Jun 3, 2010 at 7:05 PM

I agree with NovaProgrammer. A wrapper, then gradually replace the functionality as well as enhancing it. Could also be the platform for having multiple developers on the project with the two separate "targets", one being converting C++ and one being functionality additions.

Me not being a C++ man could contribute to the project in this case.

Keep it up, there's many opportunitites in this project.

/Mads

Coordinator
Sep 10, 2010 at 3:17 AM
themaze wrote:

I agree with NovaProgrammer. A wrapper, then gradually replace the functionality as well as enhancing it. Could also be the platform for having multiple developers on the project with the two separate "targets", one being converting C++ and one being functionality additions.

Me not being a C++ man could contribute to the project in this case.

Keep it up, there's many opportunitites in this project.

/Mads

 

I've warmed to the idea of a wrapper as a short-term solution. As I said to the other developer on this project "We could write a wrapper in a week, but porting it will take a lot longer". So this wrapper will will help .NET devs get to the SDK during the time while we're porting it. We'll keep the interfaces the same, so it shouldn't break code. Namespaces/using statements are the only thing that will change between the MC++ wrapper version and the full C# ported version.