I'm going to get on my web-service soapbox again. This is mostly a repeat
of what I've already said, so ignore if you're tired of me droning on
about it :-).
I opine that if the church would store the data for these kinds of apps in
a centrally-located, secure fashion, and expose a web-service to that
data, metering it out in a secure fashion, then we solve (or at least
address) most of the problems of security, privacy, design, etc, etc that have
been discussed on the list here today.
From a security and privacy standpoint, by metering out the data to
authenticated and authorized users through the web service, the church will be
able to maintain a roughly equal amount of security and privacy as to what
is now provided by the stake and ward websites. Once the data is
delivered, however (by scraping a web-app or via an API) all bets are
essentially off. I'm not saying this is the best situation, but a
well-made web-service API puts you at roughly the same level of privacy
and security as the existing centralized web-apps.
What an API gives you that a standalone app or a web-app doesn't is design
flexibility. "If you build it (an API), they will come", and the
corollary, "They will build things in ways our design team never fathomed."
With an API each developer or community can scratch their own itch as to what
language to use, what framework or platform to build it on, which design
patterns and methodologies to use, which level of QA and support to offer,
etc, etc, etc.
Data is king. I don't really care so much what the software is, as long as
the data is made available in a secure and standard format.
My $0.02.
-- Dan
_______________________________________________
Ldsoss mailing list
[email protected]
http://lists.ldsoss.org/mailman/listinfo/ldsoss
