]> git.sur5r.net Git - bacula/bacula/blobdiff - bacula/projects
Add a test for error return from bnet_wait... in heartbeat.c
[bacula/bacula] / bacula / projects
index b2c19e1b352603a56216e0dddf19be4a585ad619..d1e71862a2429fa1b066a851a5e4cde2c61f85bd 100644 (file)
@@ -1,10 +1,30 @@
                 
 Projects:
                      Bacula Projects Roadmap 
-                       03 August 2004
+                       23 April 2005
+
+The following major projects are scheduled for 1.37:
+#3   Migration (Move, Copy, Archive Jobs)
+#4   Embedded Python Scripting (implemented in all Daemons)
+#5   Events that call a Python program (Implemented in all
+       daemons, but more cleanup work to be done).
+#6   Select one from among Multiple Storage Devices for Job.
+       This is already implemented in 1.37.
+#7   Single Job Writing to Multiple Storage Devices. This is
+       currently implemented with a Clone feature.
+#-   Full multiple drive Autochanger support (mostly implemented).
+#-   We will have built in support for communications 
+       encryption (TLS) done by Landon Fuller.
+#    We will most likely have support for Unicode characters
+       (via UTF-8) on Win32 machines thanks to Thorsten Engle.
+
+
+Below, you will find more information on those projects as
+well of other projects planned at a future time.
 
 Item 1:   Implement Base jobs.
-
+  Status: Voted by users not to be implemented in 1.37
+  
   What:   A base job is sort of like a Full save except that you 
           will want the FileSet to contain only files that are
           unlikely to change in the future (i.e.  a snapshot of
@@ -34,9 +54,8 @@ Item 1:   Implement Base jobs.
           FD a list of files/attribs, and the FD must search the
           list and compare it for each file to be saved.
 
-Item 2:   Add Regular Expression Matching and Plug-ins to the
-          FileSet Include statements.
-Done: Regular expression matching.  Plug-ins are not yet started.
+Item 2:   Add Plug-ins to the FileSet Include statements.
+  Status: In progress in 1.37 using Python scripting.
 
   What:   Allow users to specify wild-card and/or regular
           expressions to be matched in both the Include and
@@ -51,6 +70,7 @@ Done: Regular expression matching.  Plug-ins are not yet started.
 
 Item 3:   Implement a Migration job type that will move the job
           data from one device to another.
+  Status: Partially coded in 1.37 -- much more to do.
 
   What:   The ability to copy, move, or archive data that is on a
           device to another device is very important. 
@@ -72,12 +92,13 @@ Item 3:   Implement a Migration job type that will move the job
            Lowwater mark
 
 
-Item 4:   Embedded Perl Scripting (precursor to 5).
+Item 4:   Embedded Python Scripting (precursor to 5).
+  Status: Implemented in 1.37 in all 3 daemons.
 
-  What:   On a configuration parameter, embed the Perl language in
+  What:   On a configuration parameter, embed the Python language in
           Bacula.
 
-  Why:    The embedded Perl scripting can be called to implement
+  Why:    The embedded Python scripting can be called to implement
           Events such as "Volume Name needed", "End of Tape",
           "Tape at x% of rated capacity", "Job started", 
           "Job Ended", "Job error", ...
@@ -85,10 +106,12 @@ Item 4:   Embedded Perl Scripting (precursor to 5).
   Notes:  This needs Events.
 
 
-Item 5:   Implement Events
+Item 5:   Implement Events that call the scripting language.
+  Status: Implemented in 1.37, but more events to complete and
+          more work to be done to cleanup the implementation.
 
   What:   When a particular user defined Event occurs, call the
-          embedded Perl interpreter.
+          embedded Python interpreter.
 
   Why:    This will provide the ultimate in user customization for
           Bacula. Almost anything imaginable can be done if Events
@@ -99,18 +122,22 @@ Item 5:   Implement Events
 
 
 Item 6:   Multiple Storage Devices for a Single Job
-Modifications to SD in progress: 1.35
+  Status: This is already implemented in 1.37 (at least the
+            initial selection of one from a number of storage
+                       devices.
 
-  What:   Allow any Job to use more than one Storage device.
+  What:   Allow any Job to specify a number of storage devices,
+          from which one will be used.
 
   Why:    With two devices, for example, the second device could
           have the next backup tape pre-mounted reducing operator
           intervention in the middle of the night.
 
 
-Item  7:  Backup a Single Job Simultaneously to Multiple Storage 
-          Devices
-Modifications to SD in progress: 1.35
+Item 7:   Backup a Single Job Simultaneously to Multiple Storage Devices
+  Status: This will probably not be done in 1.37. However, version
+          1.37 has a job Cloning feature, which permits essentially
+                 the same thing.
 
   What:   Make two copies of the backup data at the same time.
 
@@ -123,6 +150,7 @@ Modifications to SD in progress: 1.35
 
 Item  8:  Break the one-to-one Relationship between a Job and a
           Specific Storage Device (or Devices if #10 is implemented).
+  Status: Mostly done in 1.37.
 
   What:   Allow a Job to simply specify one or more MediaType, and
           the Storage daemon will select a device for it.  In
@@ -135,8 +163,9 @@ Item  8:  Break the one-to-one Relationship between a Job and a
 
 Item  9:  Implement data encryption (as opposed to communications
           encryption)
-Assigned: to Meno Abels (both data and communications encryption).
-
+  Status: Abel Menos expressed interest in this, but he is busy
+          at work.
+                 
   What:   Currently the data that is stored on the Volume is not
           encrypted. For confidentiality, encryption of data at
           the File daemon level is essential. Note, communications
@@ -151,29 +180,6 @@ Assigned: to Meno Abels (both data and communications encryption).
           http://csrc.nist.gov/CryptoToolkit/aes/
 
 
-Item 10:  New daemon communication protocol.
-
-  What:   The current daemon to daemon protocol is basically an ASCII
-          printf() and sending the buffer. On the receiving end, the
-          buffer is sscanf()ed to unpack it. The new scheme would
-          retain the current ASCII sending, but would add an 
-          argc, argv like table driven scanner to replace sscanf.
-
-  Why:    Named fields will permit error checking to ensure that
-          what is sent is what the receiver really wants.  The
-          fields can be in any order and additional fields can be
-          ignored allowing better upward compatibility.  Much
-          better checking of the types and values passed can be
-          done.
-
-  Notes:  These are internal improvements in the interest of the
-          long-term stability and evolution of the program.  On
-          the one hand, the sooner they're done, the less code we
-          have to rip up when the time comes to install them.  On
-          the other hand, they don't bring an immediately
-          perceptible benefit to potential users.
-
-
 
 Completed items from last year's list:
 Item 1:   Multiple simultaneous Jobs. (done)
@@ -188,3 +194,5 @@ Item 3:   GUI for interactive restore. Partially Implemented in 1.34
           GNOME console, and an excellent wx-console GUI.
 Item 4:   GUI for interactive backup
 Item 2:   Job Data Spooling.
+    Done: Regular expression matching.
+Item 10:  New daemon communication protocol (this has been dropped).