amireh/karazeh

Karazeh is a library for patching desktop software, suitable for use as a game launcher.

karazeh's Issues

Lower dependencies

Implement a Vanilla (CLI) renderer for users who wish not to use Qt or Ogre for rendering.

Embedding support

The ability to use Karazeh without the launcher. Technically this is already doable, but it would be better to provide an option to build as a library which the client can link against (and it would be free of any renderers and the launcher)

No more development?

Hello. It is possible to know the status of the project?

Thanks.

Persistence of patch data

In case of an interruption or termination of the patcher while patching, the client might choose to retain the data in order not to download the whole repository again

Feedback injection

The Renderer needs to be injected with errors and notices, and the feedback (from user) needs to decide the flow

Runtime resolving of patch server(s)

Either have a hard-coded list of patch servers within the binary and loop through them in a round-robin fashion until an alive one is found, or by contacting a "master" patch server to retrieve a list of patch servers dynamically..

Add platform resources

RC generation for Windows (icon) and bundle icon for mac

GTK3 renderer

For Linux there already is a Qt renderer for KDE users, a GTK one is also needed for Gnome/GTK users

Stop assigning and using a hasher singleton

Just inject the hasher into whatever module that requires it.

Launch an external application

Replace the current launcher process with the destination process (the game or application) on user demand

Restart after patching self

Optimize the downloader

Instead of opening a connection for every file to be downloaded, we should make a batch downloader using the same connection

Archived patches

Add support for receiving patch data in a tarball which will be decompressed locally to save fetching bandwidth

Support for overwrite operations

This can be achieved either by adding a whole new operation type, or by combining a DELETE op with a CREATE one. In the latter case, whenever a CREATE op is staged and finds out that the target already exists, it has to check the repository for any DELETE ops with the target as its own target.

Clearly, the second option is more complex and could be messy as things will go bad if the order of operations in the script was not properly set.

Encode the app version

The version needs to be encoded in the launcher's binary and parsed on run

Implement the Downloader

using libcurl, fetch the patch list from a remote server, store it locally, parse it, build up the patch entry list for the Patcher component to process, and download every needed file

Implement the Patcher

The patcher needs to support 3 operations:

• CREATE: create a new file locally from a remote file
• MODIFY: patch a local file using a diff located remotely
• DELETE: remove a local file
• RENAME: move/rename local files

The Patcher's repository of the operations will be populated by the Downloader as it parses the patch list.

Checksum patched files after patching

Currently, Karazeh only checksums the actual patch file but not the target after patching, which is required to verify that the patching was done successfully. In the case it didn't, a rollback is required.

Inititiate the validation from the renderer

Instead of having the launcher do it which is resulting in some race conditions using certain frontends with certain thread providors... just make it the responsibility of the renderer to initiate the validation process as well as the patching (it already does the latter) when it's ready

Decouple log4cpp from core

Provide the ability to build Karazeh without log4cpp, resort to stdout logging if possible (with thread safety)

Verify integrity of dest files before modifying

we're already using a checksum to verify the patch.. we should also verify the local file to be patched

Create a Thread wrapper

Threading should not be tied to a specific library, users should be able to use their own existing threading library, like boost, Qt, or POCO's etc

Cocoa renderer

Implement a native Mac OS X renderer using Cocoa

Choosing a default renderer

don't rely on argv for choosing a renderer, provide an option to choose the default renderer instead of the vanilla one

Win32 MFC renderer

Just as with Mac and Linux, Windows client needs a native renderer instead of relying on Qt

libtar win32 problem

libtar does not exist per say for win32 its relying on libc directly, i am as for now trying to adapt the code using libarchive, any suggestion ?

tar functions used in patcher.cpp
after (line 535 or so)
// now extract the actual tarfile
mLog->infoStream() << "extracting tarball from " << ofp;

Real progress injection

Currently progress is injected based on files retrieved out of total files to fetch... we should report real progress as in how many bytes left for transfer

Cleaner customization

• Supply patch error codes instead of hardcoded string messages
• move configuration keys to the extern config generator file instead of Pixy.h (KarazehConfig.h.in)