[wpkg-users] new web-based wpkg manager

[K.E.Jones at bton.ac.uk]

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