Option 3 (was Re: short term NWAM fixes)

On Fri, 13 Jun 2008 11:04:44 -0700
Michael Hunter <michael.huntersun.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).
_______________________________________________
nwam-discuss mailing list
nwam-discussopensolaris.org
http://mail.opensolaris.org/mailman/listinfo/nwam-discu
ss

Michael Hunter wrote:
>
> 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 biggest risk that I see here w.r.t. modality is if for
any reason the GNOME
side of things doesn't or cannot respond, then nwamd will be
hung. It will be
necessary to ensure that the NWAM daemon will not get
"stuck".

What might be useful here is if there is a way for a
re-started UI to determine
the state of nwamd, and then perform an necessary action -
this is quite useful
also in the case where nwamd enters such a state when the UI
isn't started. The
most obvious one here is that no network connection was
made, so we probably
should tell the use this as soon as possible after logging
in.

> 
> The JDS team will have to fill in details as to how
they expect to
> match any differences on the applet side.

I'll send a separate e-mail on the UI side of things...

> 
> 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.

I'll include this information in my other message.

Thanks.

Darren.

_______________________________________________
nwam-discuss mailing list
nwam-discussopensolaris.org
http://mail.opensolaris.org/mailman/listinfo/nwam-discu
ss

To handle an updated Phase 0 in the way the Michael is
proposing then from the
GNOME side we would most likely to the following, with an
aim to re-using as
much of this as possible for the Phase 1 deliverable post
2008.11:

- Make the GNOME Netstatus Applet appear by default, and
show the active
  network interface

  - The active interface would need to be
communicated/determined from NWAM
    for it to correctly reflect NWAM's state.

- Enhance the GNOME Netstatus applet to support Wi Fi
information on
  OpenSolaris, already does this on Linux, with some icon
updates to make it
  nicer than the current set if possible.

  - At present you need to have the NET_RAWACCESS privilege
before you can
    even open the network device and run the necessary
ioctl() calls to gather
    information. To overcome this, there are two options
available:

    1)  Update the network ioctl() mechanism to not require
elevated
        privileges for read-only information - such as the
ESSID, Signal
        Strength, etc.

    2)  Create a helper application that is run-able by a
console user (or
        user with specific profile), which runs with the
NET_RAWACCESS
        privilege and can provide information back to the
UI.

    Of course the ideal solution is the first one, but this
is not a trivial
    change and needs significant effort - it is planned to
be done as part of
    a larger project, but there is a risk that it may not
make it for 2008.11.

    While not ideal, the second option is possible to
achieve relatively
    easily with RBAC, the main issue will be in securing the
binary that is
    run. For example, we can define a new profile
"Network Wireless Info"
    which runs a binary as nobody, but with the specific
privilege
    NET_RAWACCESS.


- The next step is to provide the notification information
and interact with
  the user. To do this we would use a (significantly) cut
down implementation
  of the NWAM UI panel presence, which presents status
information about NWAM
  itself and would interact with the user should they need
to provide more
  information - e.g. wireless key, or select wireless
network.

  A possibly useful mechanism for Phase 0 might be to be
able to signal a
  restart/re-evaluation of state manually - akin to the
"Repair Network"
  functionality on some platforms.

  - The functionality that would be needed from the NWAM
side would be
    something along the lines of:

    - Synchronous calls would be something along the lines
of:

      - Register/De register event callback

      - Get Current NWAM State

      - Get NWAM Active Interface

      - Re sync/Re-evaluate NWAM State (Network Repair)

    - Events Mechanism, with the following event types:

      - Asynchronous information events (e.g. status
update)

      - Synchronous (response required events)

          - Wireless Network selection from a list, or add a
new one with a
            not-listed ESSID.

          - Provide the WEP key for a Wireless network - the
assumption is
            that we will still not support WPA for this
release - it is
            planned for NWAM Phase 1.

I would certainly be interested in people comments on
this...

Thanks,

Darren.


_______________________________________________
nwam-discuss mailing list
nwam-discussopensolaris.org
http://mail.opensolaris.org/mailman/listinfo/nwam-discu
ss