======================

On the ASM change issues being discussed in the tech group:

-- How many people are expected to use ASM? --
Right now there are about 25 active ASM users.  Some of the people who -would- use ASM but cannot
include Claudia, our Macaw coordinator, whose computer (Win98 as I recall) is too old to run
any of the ASM packages, and who has trouble installing software.  Each coordinator does
ASM data entry and many of them also have data entry "helpers" who do the data entry
for them.


-- How secure do you want or need it to be, including the passing of unencrypted
    packets over the Internet? --
We're recording passwords to users' accounts, donation information (IE, financials) and some
privacy-sensitive home visit notes in ASM, so we would like it to be as secure as possible,
including not presenting any data in the clear.

-- How secure is the present implementation as against a server/browser-based one? --
Currently we allow folks to download an ASM client application, which contains within it
a SSL protected connection to our central MySQL DB on @mickaboo.org.  The SQL "jdbc.properties"
file does contain a username and password to our DB, and that UN/PW can access all the information.
This means that our present implementation is not as secure as I'd like it to be, as any user with
it installed can access the whole DB if they're knowledgable about SQL.  However, our "trusted"
users pretty much have access to all that data anyway once they log into ASM (except user passwords)
so it's not a critical issue.

A server/browser based implementation would allow us to protect the actual DB access string from
the end-users, strengthening security slightly. It would also allow us to close off the DB from the
"Allow the whold world" access we currently must support in the firewall.


-- Does ASM use warrant the expense of the 'new' software, the disk and CPU use? --
The new software would allow us to present a virtual desktop over the web; we would still rely on
ASM for everything, but would cut out the "showing people how to install it and helping each of
the 25 people maintain it, ask us questions when they break their installation, etc" part. 
ASM is the most critical and useful component of our technical infrastructure, and is
one of the core reasons we run our own colo server in the first place.  Without ASM, 
we would be operating at about 20% of our current capacity for bird volume.


-- Is it wise to provide ASM access to people who are computer 'challenged'? --
We don't have much choice; the vast majority of Mickaboo are computer challenged, and some of the
folks who do the MOST to help the birds (Michelle, Claudia, etc) also have the most computer
difficulty.

-- Can access be controlled sufficiently well to avoid any problems that the
    non-skilled user might cause, in particular inadvertently doing damage
    to the database on which Mickaboo depends for everything? --
Whether or not we make any changes to our infrastructure, this is already an issue.  We mitigate
potential problems by performing nightly differential, and monthly full, backups on our SQL
database with native SQL dump tools.  This keeps our level of risk at "At most one day of work is lost",
no matter how badly anyone manages to screw the DB up.  A few months ago someone did in fact manage to
mess up a large amount of data in the DB and I was able to restore everything to within a 12 hour period,
so I consider this strategy tested and proven.


-- Should Mickaboo drop ASM completely and go with something different
    such as a fully web-based solution and truly commercial software? --
In my opinion, No.  We did a lot of research in 2005/2006 on what software would best help us to complete
our mission, and ASM was not only the most functional but the most "Free" in terms of cost, source
code, etc.  We have detailed instructions on using ASM and have customized the code to meet our needs.
Fully web-based commercial software so far has shown deficiencies that we have been able to overcome
by customizing ASM and our Wiki software.


Are there sufficient support resources to
    (a) handle the installation and implementation of any new software
    (b) deal with the usual large number of problems at start-up
    (c) convert the old data over to any new system (if required)
    (d) rewrite any/all programs that get data from the DB for the web
    (e) train users

This list... is it.  But like I said, if we use nomachine (which spawned this discussion) we're not
actually switching over to new software.  Just presenting a virtual desktop via HTTPS, with a pre-configured
ASM already installed on it.


---------------

My experience is that the ASM client is not difficult to install and/or use
in its present state, unless there is a long legacy of problems that, because
I am a late-comer, I am unaware of.   For me, the biggest problem (other than
the Mac-isms) is the awkward labelling of the fields.  Yes...there are some
other ASM-specific things that would be nice to change (such as having to
'return' birds before creating another 'move').

In all fairness, you're a technical person. The very fact that you know what "Solaris" is makes
you orders of magnitude more adept at troubleshooting and learning compelex software than most
of our volunteers ;)

So...why am I asking all this?   Well... when I was doing this sort of
stuff, I was involved in more than one database 'conversion'...from one
type of client interaction to a different one, as well as having to move
a very large relational database from one vendor's software to another.
Even though we had LOTS of expertise on both sides, it took about twice as
long as planned to make it work...and even then there were the occassional
not-understood glitches.

I'm not interested in doing any database conversion from ASM to anything else; I think that would
derail the organization and really tax our limited tech volunteer resources.  Mostly, I'm trying
to find good ways to simplify how we already manage ASM, including updates, installation,
education/outreach, peoples' work firewalls blocking outbound SQL, etc.  I think a citrix-like
web presentation layer of a virtual desktop might help us really resolve some of those issues.

Just some thoughts before jumping wildly into the forest  ;-)

Good man! :)
-m-