[prev in list] [next in list] [prev in thread] [next in thread] 

List:       wpkg-users
Subject:    [wpkg-users] [Bug 273] New: Per user install support
From:       bugzilla-daemon () bugzilla ! wpkg ! org
Date:       2012-05-15 20:47:06
Message-ID: bug-273-2 () http ! bugzilla ! wpkg ! org/
[Download RAW message or body]

http://bugzilla.wpkg.org/show_bug.cgi?id=273

           Summary: Per user install support
           Product: WPKG
           Version: other
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: wpkg.js
        AssignedTo: mangoo@wpkg.org
        ReportedBy: k.e.jones@brighton.ac.uk
         QAContact: wpkg-users@lists.wpkg.org


I wasn't sure if this thought was on the roadmap already. I suspect it is  or
I've missed something along the journey. Please ignore this if it's a waste of
thinking time :-)

 I've now started seeing smaller software developers adapt their products to be
installed by non-privileged users to cope with Windows 7's security model.

 For instance, I now have a piece of software that is basically an MSAccess
.accde file installed into the users %APPDATA% folder and not the machine's
one. Desktop shortcuts are added to the user's profile to point to that file
which circumvents the need for a per-machine install.

 As far as I can see WPKG still doesn't formally support per-user installs.I
think it's definately robust enough to handle that with trivial changes and
some subtle thinking :-)

 I would like to suggest the implementation of a /context switch with values
"machine" or "user". The /context:"machine" being assumed as the default value
and keeping WPKG compatible with current setups. The /context:"user" being an
option you'd add if you run WPKG.JS as a user logon script.

 In theory, when supplied with the "user" value WPKG would only need to change
two things;

 a) redirect the WPKG.XML path to the user's %appdata% folder.
 b) switch host matching to use the currently logged on user instead of the
host machine/IP/etc.

 I appreciate that this trivialises many things but I can't actually see many
coding hurdles. I can't actually see many operational issues either. In theory,
it should all work already it just boils down to how people implement their
WPKG setups :-)

 I have an awful feeling that I'm missing something... surely it can't be that
easy? There might be some performance issues but WPKG really is self-healing so
it could actually survive very well.

 Am I being awfully stupid?

Keith

-- 
Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
-------------------------------------------------------------------------
wpkg-users mailing list archives >> http://lists.wpkg.org/pipermail/wpkg-users/
_______________________________________________
wpkg-users mailing list
wpkg-users@lists.wpkg.org
http://lists.wpkg.org/mailman/listinfo/wpkg-users
[prev in list] [next in list] [prev in thread] [next in thread]