Hello guys,

As you may know, I have started working on the new GNS3 architecture and I would like to know your opinion about the current .NET topology file format (based on INI files). I'm thinking to ditch it because it is not easily extendible for our needs, not to talk about the portability... However, I still want a text-based file so users would still be able to "hack" topology files if needed.

I am thinking about using the JSON format which is a standard, easy to parse, extend and there are plenty of programming libraries which allows easy integration within GNS3. Maybe someone know a better format more suitable to represent a network topology?

The big downside of a new topology file is that all post 1.0 topologies would not be compatible with the new software which I agree wouldn't be great. This is why I am planning to maybe add the possibility to convert these files to the new format.

Let me know your thoughts.

Thanks,

_________________
Jeremy, GNS3 Programmer & Benevolent Dictator for Life.

Json would be a great option in my opinion too.

I think you should start from the beginning with the idea of an API which will allow us to write external tools to make use of a GNS3 daemon.

_________________

I am working on a REST API too :)

_________________
Jeremy, GNS3 Programmer & Benevolent Dictator for Life.

I'm generating .net files from templates, just replacing parts of it with variables. So as long as it's in readable text format it's totally ok :)

However, I'm also importing stuff with scripts editing gns3.ini. This would be great to be able to replace with the new REST API.

As for the choice of format I guess an alternative is XML. Me personally would prefer XML, but that's probably because it's what I'm used to and most familiar with :)

Might be some interesting info here:

http://stackoverflow.com/questions/3536 ... l-and-json

I must add though, I like the current format, very easy to read and modify :) What I'm missing the most is the API, but mostly for gns3.ini.

Normally I would recommend JSON, but in this case I think XML is more appropriate.

I'm considering the amount of work needed:

• to extend the file format (future features/devices/links/...)
• to validate the file (schema)
• to convert the file format (transformation)
• to convert part of the file as config data for another software GNS3 works with (transformation)
• to support plugins that need to keep metadata in the file

Everything can be done with JSON, of course, but I think it would need much more code.

------

For communication between software I would definitely go with JSON. ^^


Note: It's unrelated, but I love JSON and dislike XML

_________________
Dynamips maintainer and sporadic developer
https://github.com/GNS3/dynamips

If done properly, extending the file format shouldn't be a problem. Also, there are libs to validate JSON schemas. I don't know about transformation...

but the major problem is I hate XML... ;) One of the thing is that XML is not nice to your eyes and to edit.



Yep, this is gonna be JSON for sure.

Thanks for the input.

_________________
Jeremy, GNS3 Programmer & Benevolent Dictator for Life.

What about YAML?

_________________
Jeremy, GNS3 Programmer & Benevolent Dictator for Life.

Well Jeremy good job I must say you are a legend. Really I am not a geek when it comes to programming but my advice that whatever you want to do ensure that users like us who came from non gui interface still have access to modify topology when things go wrong from gui interface. Whichever file format you are going to use accessibility to the content of the file will be important to lots of users.

Thanks.

I'm not a fan of YAML, but it does present advantages when being manually edited by humans.

Advantages:

• No need to worry about quotes or escaping characters when writing the lab instructions.
• Comments are an obvious plus for any sample file/lab.
• References (+anchors) are also good, but use with caution.
• Other unimportant stuff...

Inconveniences:

• Needs an editor with mono-spaced font.
• User has to make sure tabs aren't used as indentation.
• Using GNS3, comments would be lost in the cycle open->edit->save (we can customize the Scanner of PyYAML?).

If human editability is a major factor then YAML is more appropriate than JSON/XML.

_________________
Dynamips maintainer and sporadic developer
https://github.com/GNS3/dynamips