[wpkg-users] new web-based wpkg manager
r.meier at wpkg.org
Mon Aug 4 10:41:29 CEST 2008
> 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
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'
> 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
More information about the wpkg-users