[Backalaika-developers] Result of Singletons experiment, and focus

[Nando F. <nan...@ma...>]

I myself wrote:
> I complained in a previous message that the server-host only *contains* 
> the remoted class, without any knowledge about it, since it is the 
> client that creates an instance. But the singleton pattern contains a 
> static variable which holds a reference to the single created instance, 
> if any! This has the potential of solving that problem. If the 
> server-host could get that reference and use it... I am going to try 
> this today starting with the TempRemotingTest demo.

It doesn't work. Even if the class is a singleton, the server sees its 
own instance of the service class, not the client's.
The code is in the TmpSingletonTest folder in case anyone wants to find 
out where I messed up.

Anyway, have I mentioned that Add Profile, Edit Profile and Delete 
Profile are WORKING remotely (since yesterday), and that FileServer will 
soon be integrated too? Ian, get psyched!

As leader of our international team, but without any pressure, here is 
what I think we should focus on:

Until Friday, October 1st, we must have
=======================================
- Full backups in a single machine.
- Differential backups in a single machine. Using the "archive 
attribute" in FAT filesystems, it is possible to make a second backup 
containing only files which were changed in the interim.


Possible tasks for anyone to assume now or in the near future
=============================================================
- Learn how tests are integrated in SharpDevelop.
- Write tests for any class. Nando has ideas for the ProfileSingle class.
- Fix something from the TODO task list generated in SharpDevelop.
- Minimize BackupServer and FileServer to the system tray.


=============================
Tasks for distant future only
=============================

1) Use of Backalaika in more than one computer
==============================================
Keeping in mind that FileServers are accessed through 
"tcp://Computer:Port/uri":

- ProfileSingle shall include new properties "Computer" and "Port".

- "Computer" should be validated so it can't begin with "http:" or 
"tcp:". It also cannot contain "/" or ":". In fact, there's a lot of 
characters it shouldn't contain :)

- If more than one profile references the same "Computer" but with 
different ports, Admin user should be notified of a possible problem.

- BackupServer scans ProfilesList and realizes the time has come to make 
one scheduled backup. The info it needs to access the correct FileServer 
is right there in the profile.

- When Admin is creating the list of folders to be backed up, it can ask 
FileServer directly -- no need to go through BackupServer for this. So 
Admin is now a client for FileServer, only for the purpose of obtaining 
all of its folders.

2)

3) Support for multiple volumes and partially used media. The user could 
make a list of partially used CDs (with their remaining free spaces) and 
have the program create backups that just fit into those media.

4) Backup database. Store in a database a list of all files which were 
backed up, and into which media. Create the functionality to search the 
database.

5) Database re-creation. If for any reason the database is lost, it can 
be recreated from backup media.

6) Differential backups based on the database (instead of the archive 
attribute). And additive backups (these are slightly different from 
differential backups.)

7) A GTK# user interface. This would allow the program to run on Linux 
(under Mono, the free implementation of .NET for Linux) and Windows.

8) Support for the Zip, GZip, Tar and BZip2 formats (already in the 
SharpZip library).

9) Support for file permissions (which exist in Linux but not in Windows).