Implementing a save function in a C# image manipulation app

Question

I started thinking about how to handle the save functionality of my app, and thought about 2 options:

The application has nodes like:

Blur
Contrast
Sharpen
Invert
...

1. Interpreting the saved file, like:

Blur name:"Blur01" Amount:5
...

2. Having the saved file in a self executable format, like:

Blur blur = new Blur ();
blur.Name = "Blur01"
blur.Amount = 5
...

Which one should I go for? Is there a better way to handle this?

I want the saved file to be backwards and forwards compatible.

EDIT: Thanks for all the replies. Anyone can please explain why #2 would not be future proof? Is it because one can change the load/open code for #1, but not for #2?

Answer 1

I would go with something more like the first option.

Although, in general, I think XML would be a better approach to this than making your own syntax. This is much better from a compatibility/future-proofing standpoint than trying to make your own syntax parsers for your file.

What about something like:

<Filters>
    <Blur Name="Blur01" />
    <Sharpen Name="Sharpen01" Amount=5 />
</Filters>

Answer 2

You could probably use XML Serialization, since it's widely accepted and human readable. Here's a tutorial on that: XML Serialization

Answer 3

Are you saving it in a text file?

If that is so wouldn't it be better to save it as XML?

<Blur>
 <name>Blur01</name>
 <amount>5</amount>
</Blur>

Otherwise I am not sure I understand the question :)

Answer 4

I too would go with an XML file as this will allow you to ensure compatibility both forwards and backwards.

This is because you look for properties rather than parsing the file line by line.

For example, if blur changes from:

<Blur>
 <name>Blur01</name>
 <amount>5</amount>
</Blur>

to:

<Blur>
 <name>Blur01</name>
 <amount>5</amount>
 <feather>true</feather>
</Blur>

Older versions of the app will still be able to read the file as they won't look for the feather property. All you need to do is ensure that you set default values when you create your objects so that the older files can be read without leaving unset data.

In response to the update - there's no reason why you couldn't make #2 future proof. You'd just have to do the versioning yourself.

Answer 5

The reason having a self-executing "save format" is generally bad is that today your "Blur" function might look like:

public class Blur
{
   int Amount = 5;
}

but in the future, you might improve your blur "system" to instead have something like:

public class Blur
{
   int HorizontalAmount = 5;
   int VerticalAmount = 10;
}

and now when you execute that saved file, it will no longer compile because there is no longer an 'Amount' property. Then to get backwards compatibility you will need to 'interpret' the Amount value to now mean HorizontalAmount = 5 AND VerticalAmount = 5 (or whatever).

So really, in the long run, you will be better off by having an interpreted file format from the start.