[please comment] package sharing solution

User avatar
tsuujin
Posts: 695
Joined: Fri Feb 26, 2010 12:59 am
Location: California
Contact:

Re: feature request: package sharing solution

Post by tsuujin »

Heiko wrote:The problem with this approach clearly is that items without parent folders that are part of the package would all be exported as parentless root elements. This would destroy chains, filters etc..
If the XML for each item included chain information it wouldn't be a problem at all.

trigger b is child of trigger a.
trigger b has tag element parent="trigger a"
trigger a and b have tag elements package="a package"

User avatar
Heiko
Site Admin
Posts: 1548
Joined: Wed Mar 11, 2009 6:26 pm

Re: feature request: package sharing solution

Post by Heiko »

No, this is not what I'm talking about:
Code: [show] | [select all] lua
Folder A <- package 1
   item 1
   item 2

Folder B
   item 11 
      item 112
          item 113  <- package1
   item 22
Folder C <- package1
   item 4
       item 45
   item 5
  

In this scenario the package item 113 would wrongly become a root level item and lose its proper place which is relevant if folder B happens to be a chain or filter.
The second issue I see is that you get into trouble if you move package elements via drag and drop to other packages or move elements from a package to your general system. If you uninstall the package those items would be uninstalled as well because they belong to the package that is being uninstalled. This is obviously not what you'd expect and correcting this information manually is error prone and a lot of work imho. This is why I currently favour a simple top down approach. In above example Folder A + C would be part of "package 1" and item 113 would be ignored. If item 113 is to be included in package one it would need to be moved either to Folder A or C or a new folder D would have to be created and included into package 1.

The last option would be to include Folder B into the package if item 113 is supposed to be a sub package. This leads to the only problem that has to be solved at the moment in my opinion, namely how to define sub packages properly. If item 113 is a sub package e.g. a special trigger for a special class specific package (Vadi has this sort of upgrade packages in his Lusternia system) them we'd need to introduce dependencies into the package system. In this case including item 113 into *sub package* 1 requires the existence of Folder B, a child item 11 which, in turn, has a child 112. If this is the case then sub package 1 can be installed. Otherwise you'd get an error that the package cannot be installed due to missing dependencies.
The question is how do we define dependencies in a meaninful and practical way.

Post Reply