Open GoogleCodeExporter opened 9 years ago
Hi Kenneth,
After replying to the last issue, I mentioned that I wanted to focus on
something
else other then the issue regarding Linux's issue with *. What that was that I
was
going to look at talking to you about reimplementing the user interface. I've
just
noticed this issue and I would be interested in putting some time into this and
I've
had my head around the current GUI's source and as far as I can see I'm across
the
process it takes on most tasks.
I'll be giving it a go and I've got a good idea in my of some changes I was
going to
make, so before jumping in too much could you share any ideas you have
So far I was thinking:
duplicati master program - runs in the same network as the master file server
containing duplicati backups, can create shares and set user/passwords for
ftp/share/sftp etc, can create exportable config files for. this is the main
administration tool for the master. used for technician's access, verification,
restores and others. while it works, the current gui is a little round about to
be
able to have a third computer that has saved configs of all of the backups
available
on the ftp server while not being able to overwrite or delete existing data.
duplicati client program [server] - runs on a user's main server across the
internet,
automated scheduled backups to master server - wizard style interface and/or
command
line interface for windows schedule
duplicati client program [individual desktop] - runs on individual user pc's -
needs
to be extremely accessable and straight forward. can either backup to user main
server or master server. initial configuration would be wizard style and then
streamline the restore/backup process through easy customized right click
context
menus. this program's look, feel and configuration could all be generated from
the
master program to make rapid deployment straight forward.
Like I said, just a few thoughts that I was looking at going ahead with anyway,
may
as well offer the help. I can see that you've listed what I was thinking so any
further thoughts, or would you like to palm the GUI work off to someone else?
Original comment by dddan...@gmail.com
on 15 Feb 2010 at 11:35
Huh, since I just built svn I got up to the 'Direct from files' option. Nice
touch!
Original comment by dddan...@gmail.com
on 15 Feb 2010 at 1:07
Yes, the "Direct restore" makes it much more accesible, thanks :).
I have added issue #9 for the client/server seperation.
My idea for issue #9 is that the non-GUI part should be running as a
service/daemon.
I was thinking something like the Scheduler and backup process.
The GUI client should then connect to the local service/daemon and communicate
either
through named pipes or a network socket.
I am planning to find/develop a module that allows the two components to
communicate.
I think .Net remoting is the wrong tool for this. The client should send
commands to
the service, like "Create backup", "Pause", etc. And the server should send
responses
and status updates, so the GUI can look like it does now.
Once this seperation is done, it should not be a problem to merely direct the
GUI to
another machine (using TCP).
A client could then have only the service/daemon part installed, and an admin
could
check up on backups by connecting to the service, from an admin interface. A
simpler
end-user interface (eg. readonly) could then be installed on the client.
I think your idea is targeting a much larger corporation than what I had in
mind.
(not a bad thing, just different). The "master program" sounds like something a
hosting company would run? If this program is supposed to create shares and
setup
accounts, it would be hard to make it support multiple os/ftpd/sshd
configurations.
If the client perform backups to the server, why would there be an application
on the
server? Would the client and the server communicate (other than transfer backup
files)?
Would each client/user have a dedicated server or would there be like a cluster
of
machines, all monitored by the "master program", or just one server?
If you would like to work on this, I can create a sandbox for you where you can
commit changes as you please.
Original comment by kenneth....@gmail.com
on 15 Feb 2010 at 8:46
I think the ideas you've brought up here were exactly on the money, and you are
right
in your assumption of duplicati's use. If the service can be run the gui can be
handed off to .NET application or a PHP webpage from the server to run commands
breaking the whole process up.
If you can, make me that sandbox and I'll add the changes I've been fiddling
with
today/tomorrow to the latest checkout version for a bit of review.
Original comment by dddan...@gmail.com
on 15 Feb 2010 at 8:59
Issue 228 has been merged into this issue.
Original comment by kenneth....@gmail.com
on 12 Jul 2010 at 8:52
Issue 300 has been merged into this issue.
Original comment by kenneth....@gmail.com
on 8 Nov 2010 at 9:23
Original issue reported on code.google.com by
kenneth....@gmail.com
on 9 Feb 2010 at 7:20