XML parsing

[Pwndja]

It would be nice to have XML parsing code incorporated into SFML. Especially since most people use SFML to develop games, and most good game developers use a data-driven approach, which helps keep things simpler and modular. it would help promote and facilitate data driven models.

Here is a quick blog about some of the benefits:

http://gameylittlehacker.blogspot.com/2007/01/data-driven-game-architecture.html

[Laurent]

There are many XML libraries available, from tiny/minimal ones to fully-featured/robust ones. I don't know what a SFML module dedicated to XML would bring.

Moreover, XML is a format that is often overused, and it won't help people to put support for it in all libraries in the world

[Pwndja]

There are many XML libraries available, from tiny/minimal ones to fully-featured/robust ones. I don't know what a SFML module dedicated to XML would bring.

Moreover, XML is a format that is often overused, and it won't help people to put support for it in all libraries in the world

I am not sure about it being overused to a bad extent. Anything is prone to over use but I found that XML is actually used frequently due to it's attractive qualities. Thus a natural tendents is to over use an attractive feature much like when UML diagrams we developed (see Death by UML haha love it!!) but never the less it's overuse is not a reason to de-value XML.

Here is a link which goes into some detail about a variety of different 'textual data format' / 'Data File Metaformats' to give people a fair judgment of which one is best suited for the job. Not advocating any one in particular. But XML does stand out more than any other on this site.

The other thing I was thinking is that creating your own SFML serialization code as you see fit.

The boost library has its own flavor of doing this:

http://www.boost.org/doc/libs/1_41_0/libs/serialization/doc/index.html

You might ask me why would I care to have XML or a serialization API in SFML if there are already other libraries out there?

And it is simple, I really love SFML and what you have created Laurent and anything that can enhance SFML's appeal I am a big advocate of.

Lastly since your agenda is tight due to other projects as you mentioned in my 3D addition post, I understand weeding out projects is necessary to make SFML a quality product, which is a much better thing to strive for over quantity IMO. My suggestion is to find someone on the forums who can help develop code for SFML and send it your way to have it validated and looked over before you choose to either add it or not add it. This would help off load some of the work and allow SFML to grow while your main job would be to review the extra features others would like to add in... I think this is kind of what you are already doing for the different ports but I would suggest this process be extended to the feature requests

Just a suggestion. If it makes sense to you glad I could help, if not no big deal

Awesome work as always Laurent you are doing a Great Jooorb!

BTW Washington State University (WSU) actively uses your library for their class projects each semester for the last 3 years ever since I introduced it to my profs and fellow students just thought you would like to know how far your project has branched out

PS: sorry I hit submit instead of preview before I could look over my miss spellings... Here is the correct post

[Pwndja]

O here is a list of other options if you would like to use something other than XML.

http://web.archive.org/web/20060325012720/www.pault.com/xmlalternatives.html

Also here is an artical which experesses what you mean by overused very well to help your case out

http://www.codinghorror.com/blog/archives/001114.html

Knowing how to use a tool and what tools best fit the job is key here.
So what ever best fits the module for serialization in SFML

[Tank]

At first I don't think there should be an XML extension in SFML. It just has nothing to do with it, since it's pure application-specific code, not code for a multimedia library.

And I share Laurent's opinion: XML is totally over-used. People use it for data storage, sending stuff over the network (well uhm, that's mostly (not always!) a huge bunch of overhead) and all other kind of simple stuff. Anyway, you already mentioned it: Boost has a great serialization library that perfectly works with the rest of Boost and the STL. It can do XML, text, binary stuff etc. And as a suggestion: Take a look at YAML. A tiny, but clean and easy language for structuring data. Easier than XML and often absolutely sufficient.

I don't get the point why you don't just develop it by yourself. Get the SFML sources, learn the conventions and techniques, adopt and use them for your XML storage driver. Then give it away as an inofficial extension.

I'm also very often pissed that it sometimes takes very long that new features or bugfixes get implemented in SFML. But hey, exactly because SFML is maintained by one person who really takes care of a clean library makes it what it is: Simple and Fast. However, sometimes I wish Laurent would give away some minor tasks to trusted users. But again, I can fully understand him in that point.

[Laurent]

At first I don't think there should be an XML extension in SFML. It just has nothing to do with it, since it's pure application-specific code, not code for a multimedia library.

And I share Laurent's opinion: XML is totally over-used. People use it for data storage, sending stuff over the network (well uhm, that's mostly (not always!) a huge bunch of overhead) and all other kind of simple stuff. Anyway, you already mentioned it: Boost has a great serialization library that perfectly works with the rest of Boost and the STL. It can do XML, text, binary stuff etc. And as a suggestion: Take a look at YAML. A tiny, but clean and easy language for structuring data. Easier than XML and often absolutely sufficient.

I don't get the point why you don't just develop it by yourself. Get the SFML sources, learn the conventions and techniques, adopt and use them for your XML storage driver. Then give it away as an inofficial extension.

Absolutely. Nothing to add

BTW Washington State University (WSU) actively uses your library for their class projects each semester for the last 3 years ever since I introduced it to my profs and fellow students just thought you would like to know how far your project has branched out

Thanks a lot. I'm really proud of SFML

[Jedimace1]

I think serialization would be good. Even though he mentioned XML, doesn't mean it couldn't be done with some other serialization method. About just plugging in external libraries instead of making the SFML developer(s) do it, don't a lot of things in SFML use external libraries also, like the networking and image loading? IDK why using an external library would be a problem. The serialization language the data is in shouldn't matter too much as long as we can easily load it, view/edit it, and save it back in. This would be especially good for game levels, config files, custom(optimized) file formats, etc. This would end up being useful in almost anything to do with multimedia, so why shouldn't it go in a multimedia library?

[Laurent]

Well, SFML is focused on multimedia, I don't see any relation with serialization. This is more a generic feature that a lof of programs (not especially multimedia ones) need, just like logging etc. I don't see what SFML could bring regarding this feature.

About just plugging in external libraries instead of making the SFML developer(s) do it, don't a lot of things in SFML use external libraries also, like the networking and image loading?

SFML uses specific low-level libraries to implement its features on top of that. I think there's a difference between raw BMP/PNG/JPG/etc loading and sf::Image::LoadFromFile, I don't "just plug in" external libraries

Serialization is a different thing, there are already tons of high-level libraries that provide this feature and that can be plugged in to any program. I don't feel like implementing my own one (for what?), especially when there are already excellent implementations such as boost.serialization. So why do you want SFML to implement its own serialization stuff? It wouldn't be as good as boost, for sure.

[gsaurus]

Agree.
There are a lot of good libraries specialized on these things. For the ones I have tried so far they are really simple and easy to use.
If you still don't like their interface (for example if they are not object oriented), create your own binding classes for the methods you need, following the SFML style.