Manfred Riem wrote:
Hi there,
I think we all know this. The problem is really how the Church wants us
to proceed in this. If we want an 'open-source' project to be used within
the boundaries the Church has to abide by we need to know those boundaries.
If I am mis-understanding the intent of LDSOSS, please feel free to help
me have a better understanding, but nothing I have read on the Wiki, or
this particular thread indicated that the "Church" gives two-tinkers
darn about this particular endeavor.
One poster indicated that the church is actively discussing the problem
domain (i.e. tracking advancement in Scouting/Youth programs), but that
is a very different situation then assuming that whatever a group of
people involved in this thread decide to implement is either blessed by
the church, or will be sponsored by the church. If the church did some
or all of an OSS project for use on the official Ward Websites, then
IMHO, my comments about the security elements are even more valid! It
won't matter what this group does in terms of security. The church will
either re-code it, or remove it to fit their internal policies.
I have been a scout master. I share the pain of the original poster.
Any scout master in the world would love to have a secure, online
solution that only requires a browser to access. But a global solution
won't happen on the first iteration unless the church or BSA is willing
to formally sponsor such an attempt (don't hold your breath).
In the meantime, members of this list could begin developing a solution
that works for either a single BSA unit in a disconnected mode, then in
a connected mode, and then works for multiple BSA units in a secure
manner.
Once you move past your desktop, the assumption of a shared server is
that the person managing the server is securing the sensitive
information. Once again, the security issues can be solved in stages
and iterations.
Nothing drives out _real_ functional requirements like POC's, and
iterations. Nothing kills innovation and brainstorming like a lawyer
talking about liability and privacy invasion.
I for one know there are a lot of boundaries based on the various countries
the Church has a presence in. So to just dismiss it as something we
shouldn't be discussing is like sticking your head in the sand. The
structure of the security is not being discussed here, but the boundaries.
I was responding to the assertion that any solution being developed has
to support enterprise security at the application level from the first
iteration and that we would have to get signed, notarized permission
slip from every parent and child or the men in black would be at our doors.
BTW Linus didn't create Redhat it is just one instance of a Linux distro.
You are absolutely right! Thank you for making that point crystal
clear. It was possible that someone would have mis-interpreted my
reference. My point was that if Linus had attempted to implement all of
the features added to the kernel over the last 15 years in the first
iteration, Linux, as we know and love would have never have happened.
Solve one problem at a time, and iterate. In fact, iterate fast! See
Eric Raymond's original treatise on The Cathedral and the Bazaar at
http://www.firstmonday.org/issues/issue3_3/raymond/ or
http://www.linuxtoday.com/news_story.php3?ltsn=1999-08-01-001-10-NW-CY.
...
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of A. Rick Anderson
Sent: Wednesday, June 07, 2006 10:23 AM
To: LDS Open Source Software
Subject: Re: [Ldsoss] Scout Tracking
There are fundamentally two architectures.
Standalone and online. Any discussion we can have about the merits and
demerits of both have been repeated ad-nausea for every application since
the birth of the Internet.
If we try to boil the ocean on the first pass, the project is doomed from
the beginning. Can you image what would have happened if Linus Torvalds had
tried to release Red Hat as a replacement to Minux?
Get something that works well and that installs well on a local machine.
Refactor it so that the business tier, the presentation tier and the model
tier are distinct.
Drop it on a disconnected appserver and add an additional presentation tier
to prove that the refactoring is sufficient. It won't be, so count on
additional refactoring.
Now you have a functional solution that is worth debating
security/privacy/convience issues about taking online.
The worst case scenario is, you have a solution that works for you, and that
others can install and that will work for them.
Pushing security concerns into the application logic itself, is IMHO,
absolutely poor design!!! Security and security policies are cross-cutting
concerns that should be done declaratively in a security policy manager, or
at worst, in the appserver.
As a ward member, do you really want to have to log in and validate against
every piece of functionality restricted to members on the church website.
Ex: Once I log in once, switching to the ward webmaster mode doesn't require
a new authentication. Why? Because the authentication is done at the
middleware layer, not the individual application layer.
--
A. Rick Anderson
_______________________________________________
Ldsoss mailing list
[email protected]
http://lists.ldsoss.org/mailman/listinfo/ldsoss
