SFML community forums
General => SFML projects => Topic started by: malandrin on June 15, 2011, 10:21:15 pm
-
2013/05/11 : New release : Updator 0.3 (https://code.google.com/p/updator)
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 (http://www.sfml-dev.org/forum-fr/viewtopic.php?t=3639&start=0)) 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...) :
(http://www.amnov.net/drupal/sites/default/files/images/screen_updator.preview.png)[/url]
-
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 :P
-
This is really really cool, I'll definitely have to integrate it in my project when its released
-
After some changes, here is the first release : Updator 0.1 (http://code.google.com/p/updator/downloads/list)
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.
-
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?
-
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.
-
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.
-
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 (http://updator.googlecode.com/svn/trunk/), but for my defense, a googlecode project has always a public repository :D
-
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 :P
-
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 :P
I tried but
Up
Upr
Upd
Upor
Uptor
Updtor
that's ugly :x
-
the user can rename the namespace in his code, it's not a problem.
it's a very interesting project !
-
0.2 released ! (http://code.google.com/p/updator/)
- different type of update
- multithreaded hash computing
(more infos (http://code.google.com/p/updator/wiki/Updator02_HowToUse))
-
this is really neat, is there any chance of porting to SFML 2.0?
-
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.
-
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
-
If under Windows, you just need the updator.lib and includes (IUpdateListener.h, Updator.h) to use it in your project.
You connect to your GUI with the IUpdateListener (look in the example project).
The updator.lib doesn't need any SFML1.6 libs to work.
You should be able to use your SFML2 GUI with my updator.
I prefer wait the final release of SFML2.0 to port it...
I'm eager to see your project using my lib
:D
-
When SFML 2.0 comes out will you consider dynamically linking it for the build release? Since we are most likely being using SFML there is no need to duplicate it.
Also will you consider switching it to LGPL or something less restrictive? If someone wants to use encryption/etc on their files, forcing opensource by using this lib isn't very good :roll:
-
So? Any chance of going LGPL or some other less restrictive license?
-
Oups, sorry I didnt see your post, I just changed the google project to MIT License.
I have to change the header in every files but, from now, feel free to use the source as you like.
For information, the trunk is in a mess long time ago, but announces the use of lzma compression.
I need time to finalize the 0.3.
-
alright :)
-
New release : Updator 0.3 (https://code.google.com/p/updator)
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
(Congratulations and thanks for SFML2)
-
Good to hear updates from the Updator :)