Redesign the core to make keeping track of restore points easier.

Registered by Huandari Lopez

The core as it is now, works the restore points by name. I think that is a little silly. I propose that the core track restore points with objects. The new core would:
* Create a RestorePoint object whenever a restore point is created/loaded.
* Keep track of restore points according to the RestorePoint object, for example restoreRestorePoint() would accept restore point objects.
* The restore point objects will hold all interesting (restore point - related) information. Like location, name, contents, etc, etc...

The prototype is in the following branch: https://code.edge.launchpad.net/~outofreach137/sysres/main
Though, note that a lot of the things in that branch are outdated, like the proposed ID system was removed.

This change will only redesign the core structure, so most code in methods like makeRestorePoint() will stay the same.
This is not necessarily a redesign of great priority, I know there have been more changes to the current core, so it will take some time (4 days to 2 weeks).
But I urge you to take this into serious consideration, the program is getting bigger and we need a better way of managing the restore points other than their pure names.

Blueprint information

Status:
Not started
Approver:
None
Priority:
Undefined
Drafter:
None
Direction:
Needs approval
Assignee:
Huandari Lopez
Definition:
New
Series goal:
None
Implementation:
Unknown
Milestone target:
None

Related branches

Sprints

Whiteboard

I haven't looked at the code yet, and I haven't reviewed the latest changes in trunk.

How much different is this than the other changes being proposed and implemented? I think we should discuss it on the forum. See this: https://blueprints.edge.launchpad.net/sysres/+spec/working-new-design

- I do not have enough information on what the changes (in the above link) will bring, but here we redesign the core to use an object structure, for example we create a RestorePoint object and we register it to a manager (which is really the main part of the core), where it provides the management functions (remove, restore, etc, etc). Maybe we can work something out and, in a way, 'merge' these two blueprints. P.S. The majority of the work in my branch (mentioned in the blueprint) is somewhat obsolete as the idea that I have has expanded and changed in a way, but it still revolves around the idea that we need a object-driven core. --Huandari Lopez

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.

Subscribers

No subscribers.