[wpkg-users] new web-based wpkg manager

[Rainer Meier]

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