Hiya, Before I make any comments I just wanted to say "Bravo!!!!!!". That's not a small task to take onboard! I wish you all the best in your endevours! Geez, I wish I was that smart! > From: wpkg-users-bounces at lists.wpkg.org [mailto:wpkg-users-bounces at lists.wpkg.org] On > Behalf Of mscdex > Sent: 04 August 2008 03:30 > To: Rainer Meier > Cc: wpkg-users at lists.wpkg.org > Subject: Re: [wpkg-users] new web-based wpkg manager > > 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. > XML import is good for the advanced players, which at some point I'd like to be :-) > > 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. > I'd like to agree that XSD would help but I often find that whenever I head in that direction all I end up with is a routine that says 'it's valid' or 'it's not valid' and then I have many hours trying to find a way of finding the information why it failed, or didn't. If it's used for an editor, great, but if it's used to parse hand-built stuff it can be difficult to really feedback nicely what went wrong. You'll probably need to do some heavy thinking about XSD parsing output and how it reports errors. > > 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. > That sounds eminently sensible. It would be really handy to handle things like archiving and prototyping as well if you can get some basic versioning ideas in there. As for templates, browsing for a .MSI,.MSP,.MST and having it construct a usable msiexec command... well... I think I'm going to go a find a dark corner to gently drool in!!!!!!! > > 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. > Buzzword or not, it really enhances speed and user experience so I'm with you there! > > 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? > If I stick my oar in for a second, a couple of wishlist things for me include; a) Devolved Users: It'd be oh-so-nice to be able to devolve duties out to staff in a secure way. That's really a complex thing but if you can keep it in mind in the design it'd really give WPKG an extra boost on 'sales' to people :-). I'd guess the basic user levels concepts are, architect, packager, deployer, reporter. ie someone that handles the system as a whole, someone that create packages, someone responsible for twiddling with the hosts file and someone that might want reports on it. b) The other thought is a bit selfish but might be cool. I feel really guilty about it because I haven't yet got the ball really rolling on it and it's just a pipe-dream idea. I was sort of orientating the WPKG.Utility stuff towards it being abstract enough to be re-designed as XML-based plug-ins. (Have a look deeply at the script design I'm using and I think it becomes apparent.) I'll try and find a bit of time to write this up but it's a bit tough time-wise here at the moment so bear with me! You can imagine the pipe-dream geek moments of having with the idea of plug-in test support though! {big grin} > > Brian > On 8/3/08, Rainer Meier <r.meier at wpkg.org> wrote: > Hi, > > mscdex wrote: > 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!) > > 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 ;-) > 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. > > So now let's list some suggestions: > - XML import/export > 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. > 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. > > - Support XSD > 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. > 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. > > - Templates > 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. > > - Ajax > 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. > Well, this is not a blocker but could for sure increase speed and usability. > > - Usability in general > 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. > 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). > KISS principle, most definitely! Any stuff I've said here should not get in the way of anything you can do on that front and you've really picked some heavy work sp you're the man!!!! (well I hope that wasn't sexist but...) The 80-20 rule is always good to think about too! > > Just my five cents for now, > Rainer Muchos Respect to both of you! Keefy |