Hi, mscdex wrote: > Thank you for the suggestions. Regarding the XML import/export, I'm not > sure what the purpose of this would be? The way I imagined the frontend > to be was that it would work directly with the xml files on disk and > none of that information would be stored in a database. OK, this idea sounds good for me too. However there are some points which have to be taken into consideration. If the web GUI directly edits the XML files, then the same server is supposed to run the GUI as well as the windows share (or Samba) which might not fit some environments (no web server service on file servers). I am not concerned about speed as we are not talking about millions of XML files but rather about less than 100. Personally I thought the GUI would store its package information into a DB backend or a local storage. In such case XML import/export would be very helpful for migration purposes too. The current WPKG WEB supports downloading of packages.xml (including all package definitions) using HTTP protocol (including basic authentication). Personally I am using this option at the moment. It is quite an efficient way to read the XML files. Reading them from a CIFS share is less efficient. > XSD looks like it could indeed be useful. Personally I have never used > XSDs, so I'd have to learn the format, but that shouldn't be a problem > really. Also I do not have a lot of experience here. However I managed to write some XSD files which reflect the current status of WPKG (available within the SVN repository). But for sure this is something I would like to enhance when I find some time (it's on my tasklist). > Your templates idea is a good one. One of the ideas I had been thinking > about recently was the possibility of having a central repository that > would hold "packages." These would include not just the actual xml > contents of the wpkg package itself but also metadata like any sort of > possible software requirements needed by install/upgrade/remove steps > (e.g. pskill, taskkill, or any other utility) or other things they > should know about the package. Network administrators using the web > interface could then pull in these packages from the repository at the > click of a button and have it inserted into the packages directory or > packages.xml file. This would save a step or two and might make things a > little more streamlined. OK, the idea of metadata (and which kind of metadata) is not yet fully clear to me. But don't be irritated because of that - just go on. Things like dependencies can be entered directly to the package XML files and I use this quite often (for example some installation scripts I use depend on shortcut.exe, so the package depends on the 'shortcut' package). > As far as usability is concerned, I'm thinking about using an MVC > framework ala CakePHP. This way, if for some reason the default view > does not "work" a user generated template can be used instead. Although > I will aim to create a useful default interface from the get-go, I think > having that option on the table might be appealing to some? Using MVC concept should be the minimum requirement for such a GUI framework I think. Clearly defining the interfaces of the controller part is another crucial thing which enables somebody to replace the GUI part by something else if he likes to. I just intended to point out that our default GUI should somehow be usable and we should think also about non-functional requirements like usability in order not to forget about such things. It is nice to use an MVC architecture but it is less nice to tell potential customers "yes, we have a web GUI but no, it is not usable but hey, you can write your own one". Thanks, Rainer |