Updator (2013/05/11 : new version 0.3)

[malandrin]

2013/05/11 : New release : Updator 0.3

Major changes :
- SFML2
- files on server are compressed (lzma compression)

There is a compiled version of the example in the package 0.3 : https://code.google.com/p/updator/downloads/list


Hi,

I come here (from the french forum) to introduce my open-source project called Updator.
It's a small application wich synchronizes (updates) the local files with the files from the server (RSync style).

The server is a simple HTTP server. There is a folder on the server wich contains all updated files and a special file.

This special file contains the path and the hash of every files to update.

So :
- the user launches the app (the client)
- the client download the hashs file
- for each file (with the path) the client compare hashes (computed local and the one in file)
---- if hash ok -> the file is already updated, nothing to do
---- if hash not ok (or no local file) -> donwload the file and replace

I created a googlecode project : http://updator.googlecode.com
And a forum to discuss about it if needed : http://www.amnov.net/forum/viewforum.php?f=26

I'm using SFML for Network and GUI.

The current version is working but it could be improved a lot and optimize.
Here is the list of things I have thought to do : http://code.google.com/p/updator/issues/list
If you have more ideas, I'll be glad to hear them
I hope find some people to help with this project, even if it's not a big one.

Do not hesitate to ask more details or explication.

Screen of the client (I'm not designer...) :
[/url]

[Haikarainen]

This is cool! Been thinking of pulling my thumb outta my ass and get to creating my own patcher/updater, but this would do just the trick

Saw this stuff on the french forums some day ago but dont understand french

[WitchD0ctor]

This is really really cool, I'll definitely have to integrate it in my project when its released

[malandrin]

After some changes, here is the first release : Updator 0.1

And here is a short howto : http://code.google.com/p/updator/wiki/Updator01_HowToUse

As it's my first opensource project, don't hesitate to advice/criticize me.

[Nexus]

As it's my first opensource project, don't hesitate to advice/criticize me.

You say Updator is open-source, and according to your Google Code site, it is licensed under GPL. But you don't provide the source code, only include and lib files?

[malandrin]

As it's my first opensource project, don't hesitate to advice/criticize me.

You say Updator is open-source, and according to your Google Code site, it is licensed under GPL. But you don't provide the source code, only include and lib files?

You should be able to svn checkout the project at this address http://updator.googlecode.com/svn/trunk/

The zip file is just for using compiled lib.

[Nexus]

Ah, okay. Maybe you should have mentioned that in this thread

The project looks good so far, an auto-updater might indeed be quite useful. I took a look at your code and have some suggestions:

• I would put everything in a namespace specific for your project (not sf).
• To initialize member variables, use the constructor initializer list instead of assignments in the constructor body. Then, you don't need std::memset() to fill the arrays with zeros.
• Does Downloader's member sock really need to be a pointer? Without a proper copy constructor and assignment operator, copying Downloader objects may lead to undefined behavior. But I think sock could as well be of type sf::SocketTCP.
• Same for downloader_thread in main(), it can be a sf::Thread without manual memory management. Like this, the memory leak disappears. Generally, avoid new and delete if it's not really necessary. Consider the use of smart pointers (std::auto_ptr, or std::unique_ptr in C++0x) in the cases where it is necessary.
• MainWindow.h contains a #include <SFML\Graphics.hpp> with a backslash. If you plan to make your code portable, you should use a slash /.
• Prefer constants (e.g. const unsigned int) over #defines.

[malandrin]

Thank you for these advices.
I commit some changes.

The main class is now Updator::Updator wich is using a Updator::Downloader.

Updator contains a Downloader pointer (so a dynamic allocation) to avoid to #include "Downloader.h" in Updator.h.


You are right, I should say that my project sources are on this svn, but for my defense, a googlecode project has always a public repository  

[Nexus]

Yes, it was also my fault that I didn't look precisely on the Google Code page

By the way, namespaces are usually rather short (up to 5 letters) because one has to type them all the time... But it's ok

[malandrin]

By the way, namespaces are usually rather short (up to 5 letters) because one has to type them all the time... But it's ok

I tried but

Up
Upr
Upd
Upor
Uptor
Updtor

that's ugly  :x

[danman]

the user can rename the namespace in his code, it's not a problem.

it's a very interesting project !

[malandrin]

0.2 released !

- different type of update
- multithreaded hash computing

(more infos)

[WitchD0ctor]

this is really neat, is there any chance of porting to SFML 2.0?

[malandrin]

When sfml 2.0 will be released, but I don't know if it's expected soon.

Is it for the Updator.lib or the crappy example ?
The Updator.lib doesn't make a lot of call to SFML, you should easily port it to SFML2.0 yourself.

[WitchD0ctor]

I got version 0.2 to work using the simple console version with my project, Some things have changed in the socket class (there is no more isValid member function for example) and I have absolutely No networking experience so I didnt want to muck up your hard work by porting it myself. Either way, sfml 2.0 would be good for adding my own GUI stuff and not much more than that and thats not incredibly important right now anyway.

Awesome job on this, I'll definitely be using this heavily on current and future projects