Directories and Packages Architecture

[pzaino]

I have been playing with PackMan for a while, to measure all the limitation it may have and ensure I can design the best possible Package architecture in order to ensure smooth updates for all users.

After playing with different approaches, I came up with the following design, this should ensure no issues coming from PackMan intrinsic limitations over time:

1. The most basic dependence is going to be called DME-Base and will contain the following RISC OS Apps:

- !DeskCfg
- !DeskRes

DeskCfg will be stored in Boot:Choices (and on RISC OS 4.39 and 6) in Boot:Choices.Default

DeskRes will be stored in Boot:Resources

DeskCfg is just a "meta-app", so basically just a directory structure and relative !Boot/!Run/IconSprites etc. and should never been updated over time. This because PackMan present a quite serious issue. When updating a package that contains configurations and/or extensions it will simply backup the existing one and then write a clean new one instead.

This is a problem for the DME, which requires a special configuration path that will contain all components configurations and customization. The Config Path for the DME can be provided also via Network, so it's possible in a classroom for example to pre-configure all the client desktops from a single point and distribute the entire configuration via network and in read-only mode.

DeskRes is also a meta app and allows the storage of all the DME components.

I am also thinking of adding a DeskConf (RISC OS !Configure Plugin), but I haven't made up my ming yet on how to organise this.

All the other components in the DME Engine (included DME-Core) will have DeskCfg and DeskRes as required dependencies and will install their pieces in those two (and eventually in DeskConf for the configuration).

DeskCfg internal architecture
At this time I am thinking of using all short names for the internal directories in both DeskCfg and DeskRes. Also DeskRes will check (at boot) if DeskCfg has been seen by the Filer and if not will force a Repeat FilerBoot in Boot:Choices. I have noticed that this also helps with !ZapUser and other applications that uses the same approach as DME to store their configs.

!DeskCfg
 |
 +- !Boot
 |
 +- !Run
 |
 +- !Help (an Obey that will open an Help file in the !Territory configured language) 
 |
 +- !iconSprites(xx)
 |
 +- DeskCfg (a directory containing the entire configuration of all DME Engine and components organised in subdirectories)
 |
 +- Resources
        |
        +- UK
        |
        +- US
        |
        +- Italy
      (etc)

DeskRes internal architecture

Similar to DeskCfg, only difference is that instead of an internal DeskCfg directory it will have a DeskRes directory to store all the components. Also DeskRes is organised in subdirectories.

DeskRes will force a Repeat Filer_Boot in Boot:Choices if DeskCfg has not been seen by the filer yet (when the RISC OS Filer is processing the Filer_Boot for DeskRes itself). It will also force a Repeat Filer_Boot for all the subdirectories contained in DeskRes itself if DeskRes$Dir was not yet defined.

Conclusions

This should be enough to ensure that the update process would never break the user customisations and still allow DME to have the flexibility of receiving the entire Desktop configuration and components set from the network if needed.

If someone has any thoughts on the matter please let me know, thanks in advance for the help :)

[update 01]
Link to DeskCfg "source" repo: https://github.com/RISC-OS-Community/DME-Desk-Base
[/update01]