On Fri, 13 Jun 2008 11:04:44 -0700
Michael Hunter <michael.hunter at sun.com> wrote:
[...]
> 3) applet
> Summary: create an applet to seperate policy and interface
> Estimate: 6 engineer weeks (possibly shared with the JDS team)
> Sizzle: medium
> Risk: high
>
> Description:
> In Phase 1 NWAM is split into at least two different long running
> processes[1]: one representing policy and the other the UI. The idea
> would be to use the same idea for 2008.11. Have an applet living in
> the toolbar which gives status and remove all of the UI elements from
> nwamd(1). This solves the problem of nwamd(1) determining who owns the
> console, allows for a more expressive dialog with the user using real
> graphical elements, and allows for things like mouse over status.
> Given this split between policy and UI this option has the most effect
> on nwamd(1) and is most likely to uncover further problems with the
> Phase 0 codebase.
[...]
The fundamental center of this feature set is to split NWAM into two
parts: the policy engine nwamd and a UI component which is represented
on the Gnome menu bar. An assumption is that the user is running
Gnome. No support will be added for the console user.
Another assumption is that the changes made to the daemon will not be
long lived. They will be replaced by Phase 1 with a fairly different
implementation. The UI could share a fair bit of implementation with
its Phase 1 counterpart. Furthermore library code from Phase 1 could
be used by both the daemon and the applet for communication.
One of the core problems with the Phase 0 daemon is that the modality
of the UI got mixed into the daemon. Removing this could cause
significant risk. Instead the idea will be to leave that part of the
daemon alone. Within those parts which are modal the daemon will block
and wait for the UI to complete where in Phase 1 it might go back to
processing events. In some places some level of parallelism is
achieved in Phase 0 via the use of threads. This will continue.
The JDS team will have to fill in details as to how they expect to
match any differences on the applet side.
In order to approach this problem the 0th order task would be to
specify what needs to be done in order to further support the JDS teams
efforts in this area. The goal will be to get to a high level
specification and design done by Monday COB Pacific.
mph
Applendix: A rough WAG as to how the rest of the work would fall out
follows:
1) Design interaction between daemon and applet
ROM: 1 engineer week
Dependencies: This needs to be done with whomever does the applet work
This should be fairly close to what we've done with Phase 1. I've
written and tested code which does a fair bit of this so it should be
mostly a matter of documentation and review.
2) Strip zenity interaction out of daemon and replace with interaction
with applet
ROM: 2 engineer weeks
Dependencies: none
Along with the above I've done this with Phase 0. I have a text
program which allows for test. I'll have to redo this work as Phase 0
has drifted away from this code base. Also I'll rebuild the text test
program so as I decouple myself from the GUI work.
3) Test
ROM: 2 elapsed weeks, 1 engineer week, possible additional test resource
Dependencies: applet, possible tight interaction with applet engineer
If the engineer responsible is able to build the applet on his own this
should mostly be in the daemon engineer's lap. Access to a variety of
platforms, and an additional test resource would increase quality and
decrease future maintenance costs.
4) ARC, Putback, etc
ROM: 1 engineer week, 2 elapsed weeks
There is UI work here and integration between consolidations (assuming
the applet is in the JDS consolidation).
