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.<br>
<br>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.<br><br>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.<br>
<br>Ajax is something I had already planned on using. As you mentioned, operations like re-ordering priorities of packages, checks, and other things would greatly benefit from functionality like this and allow the opportunity to be much more efficient.<br>
<br>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?<br>
<br><br>Brian<br><br><div><span class="gmail_quote">On 8/3/08, <b class="gmail_sendername">Rainer Meier</b> <<a href="mailto:r.meier@wpkg.org">r.meier@wpkg.org</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi,<span class="q"><br>
<br>
mscdex wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Lately I've been tinkering with the idea of creating a new web-based utility to manage wpkg profiles, packages, etc. The existing wpkg web utility is outdated (last updated in mid-2007ish) and the maintainer for it appears to be no longer active. I believe having a decent (and active) frontend project would help a lot of people, even those of us who don't mind manually modifying XML files and such. It might even allow many of us to "sell" wpkg to some of our clients by showing them how easy it is to manage software deployment (for free!)<br>

</blockquote>
<br></span>
I absolutely agree. Personally I am still using WPKG WEB even if it is unmaintained and I cannot use some features introduced by myself into WPKG ;-)<br>
In fact I could export the XML files at any time and continue to use XML files. I don't mind editing XML files but WPKG WEB provides a more nice interface and it is good if some GUI is available to show to some administrators looking for a software deployment tool like WPKG. So I really support the idea to develop a new web-based package management tool.<br>

<br>
So now let's list some suggestions:<br>
- XML import/export<br>
I think it is important to support exporting the resulting XML files. This helps for debugging or in case somebody will switch from GUI to manual XML edit.<br>
The import feature seems to be very important to me in order to support smooth migration. Probably it does not make much sense to migrate the current WPKG WEB database but just export all XML files from WPKG WEB and then import the XML files to the new GUI.<br>

<br>
- Support XSD<br>
I worked on some XSD files to define the syntax of package and other WPKG XML files. By loading the XSD file within the GUI it should be possible to provide an editor which displays a nice GUI with pull-down lists for enumerated lists, check field contents by XSD definition and so on. I am also thinking about a kind of "advanced" button on the package edit page which would allow to insert/edit all attributes according to XSD (in case the GUI does display only the most frequently used ones). This would allow to support new syntax, attributes and nodes even if they did not exist when the GUI was created.<br>

There might be a "plain-XML" tab/button as well to allow direct edit of the XML source (which is of course validated by XSD). This could even convince hard-core XML administrators to use the GUI as it offers full flexibility to them.<br>

<br>
- Templates<br>
Most packages are based on a small number of installers. For example NSIS, MSI and InnoSetup are very common. It would be nice if there would be some (customizable and extensible) templates available to the administrator. So one could click on "create new NSIS package" and a new package which already includes "%SOFTWARE\softXY\setup.exe /S" as the installer command and the likely.<br>

<br>
- Ajax<br>
Well, nice buzzword. I hate buzzwords. But in this case I see some very nice use cases. The current WPKG web interface for example allows to re-order checks or commands. However continously clicking on the "^" or "v" button to move an item up or down is annoying. The same applies for different sections of the XML files. I like the tabbed interface of WPKG WEB but it needs to reload the whole page on each operation.<br>

Well, this is not a blocker but could for sure increase speed and usability.<br>
<br>
- Usability in general<br>
Unfortunately this is nothing which can be described in general. I think it needs to be a process of discussion. Especially developers tend to create huge, complicated GUIs which provide very poor usability. I am sure we have some people on the list which could then contribute to make the GUI better. I just suggest to be open to usability comments or even better: ASK FOR USABILITY COMMENTS.<br>

In general I suggest keeping the main GUI slim and easy to use with some extension points (like "advanced" or ">" buttons to open an advanced edit panel or similar stuff). I would say 90% of the packages can be done with very few configuration and 80% of the WPKG features are only used in very very rare cases. Try to follow the KISS principle (Keep It Simple and Stupid).<br>

<br>
<br>
Just my five cents for now,<br><span class="sg">
Rainer<br>
</span></blockquote></div><br>