Alan_Brown wrote:Although #12 doesn't specifically mention Church software, any reasonable interpretation of the context of the guidelines would acknowledge that the prohibition on the use of "tables, schemas, and the like" means you may not use the tables and schemas that underly Church software.
I agree with you. Its very possible the thinking behind this here is to ensure no third-party writes to those files and thus potentially cause a lot of damage. My questions (with a smile) were merely to highlight many things can be interpreted in many different ways. Someone mentioned the situation around Adam and Eve which is always a good one.
boomerbubba wrote:It does seem that the language could not have been intended to refer to the export files, or those export files would not have been provided as they have been for years. Such a reading would thus be absurd.
I totally agree with you here.
RussellHltn wrote:I'm not sure either. But it's written policy and seems to touch on what you are doing. It's a point that I thought should be tossed out for discussion. Isn't it better that this is worked out before you start coding rather then after?
I think its well worth mentioning. Part of my original email said I would pass on my idea and approach to Tom Welch and his team to ensure I wasnt going into an area with an approach that the church would feel uneasy about. I think thats a better approach. Ironically the security side I think will heavily impact both development time but also installation for those who wish to use it in multi-user mode so no doubt first version will just be single-user.
RussellHltn wrote:As for what it means, is it a prohibition against anything that reads the MLS database directly? Is it to insure that MLS is THE record keeping software of the unit and that it not be replaced by something else? If that's the case, then I don't see a problem with what you are doing.
Thats also how I think about it. Its in the church's interest to ensure data integrity and make sure noone else reads or writes to it directly.
RussellHltn wrote:But if it's something against "third party record keeping software" then that's something to think about. It's one thing to use the export as a computerized printout - to be able to search and find the information needed. But if this application collects and stores additional information, then it might be viewed as something that might be prohibited.
I am thinking that "third party software" here is in the context of reading the church schema files directly. As for storing additional information I cannot see what the church would have against that as its no different to a typed up word document with sensitive information which surely must be something which is done a lot.
RussellHltn wrote:As far as what kinds of notes are kept, based on another thread about record keeping, it's one thing to have the equivalent of a "area book" where missionaries pass a set of notes to their replacements. It's quite another to have a dossier on members that is passed around between ward leaders. You might want to carefully consider what information your application will collect and how it will be stored or distributed. Free-form notes could be abused, but a check box for "follow-up with Home Teachers" would be safe.
Free-form notes I cant see the problem with as I believe a Word document is just as much of free format so a careful person will continue to be careful. What I do agree with you about is how this data is distributed. That is not an area to be taken lightly. My initial thoughts was to let some of the control go through the Bishop and any data transmitted would need to be encrypted and also with the possibility of using public and private keys.
I do think some training to the end-user here would be a good idea to emphase common sense in what is recorded.
Personally I think websites like those who are recording HT/VT and DutyToGod are touching the boundaries of what I personally feel comfortable with but then again I dont know how heavy their data is encrypted. It's not an area I will take lightly. But as I said that conversation I think is one which is better to take up with Tom and his team rather than the forum.
If I was they creator of those sites I would donate the work to the church so the data can rest on church servers. Just think of the blessings :rolleyes:
RussellHltn wrote:But, there's a bigger problem. According to this thread, CSV files will be done away with and replace with vCard. I wouldn't think about doing anything until that's settled.
I dont think that will affect my ideas. Its just another way of expressing data. vCard has in fact more potential for syncronising additional data. This all depends on which version of vCard the church will use and also how much of vCards functionality it will make use of. One thing is for sure, it wont be less than CSV format :rolleyes: (unless they limit the fields they are already exporting). vCard is pretty good if you want to write something that can syncronise two calendars as it is easy to express changes.
What I did ponder upon was more why the church decided to do away with the CSV format in the next version. If its coming back in later versions then maybe it was a simple "upps".