From Fedora Project Wiki

mNo edit summary
m (→‎Final timeline: new section)
 
(10 intermediate revisions by 2 users not shown)
Line 12: Line 12:


== Detailed work plan of backend ==
== Detailed work plan of backend ==
'''Main classes of backend:'''
===Main classes of backend:===


''Kronikarz.XMLHookSettings'' (modules — xml.sax, string, os.path) — an in-programm storage of software settings:
'''Kronikarz.XMLHookSettings''' (modules — <del>xml.sax</del>, <del>string</del>, xml.dom.minidom, os.path) — an in-programm storage of software settings '''~3 days of 1 week''':
* Parsing settings from XML file
* Parsing settings from XML file
* Possibility to creat XML files
* Possibility to creat XML files
* And store settings parameters, as I think /[[User:Elemc|Elemc]] 18:32, 26 May 2010 (UTC)/
''I'm not assured that usage xml.sax - good idea, during work we will see.'' /[[User:Elemc|Elemc]] 18:32, 26 May 2010 (UTC)/


''Kronikarz.ArchiveProcess'' (base class) and Kronikarz.ArchiveProcess(ZIP|TarGz|...) (derived classes) (modules — working with archive, strings, os.path):
'''Kronikarz.ArchiveProcess''' (base class) and Kronikarz.ArchiveProcess(ZIP|TarGz|...) (derived classes) (modules — working with archive, strings, os.path) '''~3 days of 1 week''':
* Archiving/restoring of files from Kronikarz.XMLHookSettings — in base class
* Archiving/restoring of files from Kronikarz.XMLHookSettings — in base class
* Support different archiving formats — in derived class
* Support different archiving formats — in derived class
''I'm sure this class only for archiving, not for restore. Make a two base function in one class - not good idea. Please fix it.'' /[[User:Elemc|Elemc]] 18:32, 26 May 2010 (UTC)/


''Kronikarz.FilesChangesDB'' (modules — sqlite3, os.path, md5, string):
''Maybe creating two base classess: Kronikars.ArchivePack and Kronikars.ArchiveUnpack with derived classess?'' /[[User:M0nhawk|m0nhawk]] 27-05-2010 19:16:22 UTC/
 
'''Kronikarz.FilesChangesDB''' (modules — sqlite3, os.path, md5, string) '''~6 days of 1 week''':
* Hashing of settings files/folders to watch after changes
* Hashing of settings files/folders to watch after changes
* Data stored in DB:
* Data stored in DB:
** name of package
** name of package ''for what this field in a database?'' /[[User:Elemc|Elemc]] 18:32, 26 May 2010 (UTC)/
** files/folders
** files/folders
** hash
** hash (checksum) /[[User:Elemc|Elemc]] 18:32, 26 May 2010 (UTC)/
** last time check
** last time check ''for what this field in a database?'' /[[User:Elemc|Elemc]] 18:32, 26 May 2010 (UTC)/
** archive name
** archive name ''is a good idea, for restoring incremental backups'' /[[User:Elemc|Elemc]] 18:32, 26 May 2010 (UTC)/
 
Here is only things that discussion of which has taken part with mentor.]
 
-- [[User:M0nhawk|m0nhawk]] 26-05-2010 19:18:44 UTC
 
== Final timeline ==


Here is only things that discussion of which has taken part with mentor.
*June:
-- [[User:M0nhawk|m0nhawk]]
**01-15: realization of settings class (keeping and writing information about files and folders of applications in xml-files) and basic for backup/restore functionality;
**15-22: realization of database for check of changing of files;
**22-30: realization of daemon for backup and restore on schedule or/and on files changes.
*July:
**01-12: testing of basic functionality;
**12-19: wrtiting of GUI to backends;
**19-26: testing of GUI functionality;
**26-28: final checking of our app;
**28-31: creating of packages for Linux distributions.

Latest revision as of 10:51, 13 June 2010

General Feedback

Please work on the following : [1] Mentor's comments and, a non-mentor community member feedback, [2] a bit more detail about your timeline, currently it is much too broad and, does not include parts where you investigate any dependencies/blockers or, factor in testing and user-feedback

-- sankarshan

Detailed timeline

After the primary negotiation and work sharing it the detailed timeline will be developed. As now it is not clear, what each of students will do, and also each of them can meet complexities. And I also would like to hear students opinions on the detailed timeline and this discussion is in process now.

-- Elemc 18:30, 25 May 2010 (UTC)

Detailed work plan of backend

Main classes of backend:

Kronikarz.XMLHookSettings (modules — xml.sax, string, xml.dom.minidom, os.path) — an in-programm storage of software settings ~3 days of 1 week:

  • Parsing settings from XML file
  • Possibility to creat XML files
  • And store settings parameters, as I think /Elemc 18:32, 26 May 2010 (UTC)/

I'm not assured that usage xml.sax - good idea, during work we will see. /Elemc 18:32, 26 May 2010 (UTC)/

Kronikarz.ArchiveProcess (base class) and Kronikarz.ArchiveProcess(ZIP|TarGz|...) (derived classes) (modules — working with archive, strings, os.path) ~3 days of 1 week:

  • Archiving/restoring of files from Kronikarz.XMLHookSettings — in base class
  • Support different archiving formats — in derived class

I'm sure this class only for archiving, not for restore. Make a two base function in one class - not good idea. Please fix it. /Elemc 18:32, 26 May 2010 (UTC)/

Maybe creating two base classess: Kronikars.ArchivePack and Kronikars.ArchiveUnpack with derived classess? /m0nhawk 27-05-2010 19:16:22 UTC/

Kronikarz.FilesChangesDB (modules — sqlite3, os.path, md5, string) ~6 days of 1 week:

  • Hashing of settings files/folders to watch after changes
  • Data stored in DB:
    • name of package for what this field in a database? /Elemc 18:32, 26 May 2010 (UTC)/
    • files/folders
    • hash (checksum) /Elemc 18:32, 26 May 2010 (UTC)/
    • last time check for what this field in a database? /Elemc 18:32, 26 May 2010 (UTC)/
    • archive name is a good idea, for restoring incremental backups /Elemc 18:32, 26 May 2010 (UTC)/

Here is only things that discussion of which has taken part with mentor.]

-- m0nhawk 26-05-2010 19:18:44 UTC

Final timeline

  • June:
    • 01-15: realization of settings class (keeping and writing information about files and folders of applications in xml-files) and basic for backup/restore functionality;
    • 15-22: realization of database for check of changing of files;
    • 22-30: realization of daemon for backup and restore on schedule or/and on files changes.
  • July:
    • 01-12: testing of basic functionality;
    • 12-19: wrtiting of GUI to backends;
    • 19-26: testing of GUI functionality;
    • 26-28: final checking of our app;
    • 28-31: creating of packages for Linux distributions.