Re: [Ldsoss] Scout Tracking
I sorry I'm late responding, but you really should check out: http://jaynorth.net/?view=scouttracker I've mentioned this project on the list before. He chose the same toolset and approach that you did, and my brother has been using it with his troop for over a year. It is an excellent start. Richard Esplin On Friday 18 August 2006 17:48, Oscar Schultz wrote: On Tuesday 15 August 2006 8:24 pm, A. Rick Anderson wrote: Oscar Schultz wrote: On Monday 10 July 2006 10:04 am, Tom Welch wrote: Good start Oscar. It is a start. I'll add the changes, modify into sql and repost. Did you ever get the table definitions done as SQL? Hello list, Between scout camp, yw camp and family reunions I done some but not as much as I wanted to the tracker. Below is what I currently have The question for the list is how to make the user interface secure. The tools I have selected are mysql, php5, pear, apache2, and linux as the base os. The application will run as a web server (server side code rather than javascript) and will require cookies. I have been reading about cross-side script attacks (xss). xss looks to be a serious problem since it uses man in the middle to steal cookies. Anyone have some ideas how to harden a web application so I can avoid design problems upfront. thanks oscar snip ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss
Re: [Ldsoss] Scout Tracking
Steven H. McCown wrote: Actually, the only parents who are that out of the loop are those who either choose to be or don't concern themselves enough to ask. A little how's my son doing? to the Scoutmaster would give a better picture. Most Scout Masters are excited to talk with parents. Posting minor children's information to the internet and trying to secure it with software that isn't secure won't really cure that. Yes, ideally, if the parents were on top of things then the scoutmaster's job would be easy. In the scout handbook there is a place for recording and tracking everything and the ideal parent would make sure that is up to date. There would be no need for scout tracking software and this discussion. Ideal parents wouldn't be asking how's my son doing? because they would know. They actually know better than the scoutmaster and other YM leaders. However, out of the 30+ YM we have I would say there are only about 5 that have ideal parents. With the less than ideal parents we have to be more proactive, however. As for the $40/year and writing a new software package, that's great, I support it. My only complaint is with posting minor children's information (as discussed on this list) to the web. Legally, the church will have to provide an opt-out mechanism (in several countries besides the US). There are ways to deal with this... (1) Minimize the amount of personal information. While it would be nice to have pictures and other personal information about each scout it is not necessary. In fact, the name of the scout doesn't even need to be recorded. Simply just assign them a number. (2) Let them opt-out. If a parent doesn't want their son's information on-line then, by all means, let them opt-out. Let them track their son's progress. Like I mentioned above some parents do better than we do. (3) Have security minded folks like yourself do a complete security audit of the code. If there is a security problem then find it and let the developers know. People keep mentioning parental involvement and parental tracking. Here's a thought, it might be valuable for tithing payers to monitor their charitable donations and compare their records to the church's. If only FIS was online accessible (with appropriate security to only monitor ones own donations), then we could all go online with a great tool to assist in financial planning. This would ease a busy person's burdens and make it so they never had to go ask the ward clerk for a printout. Why is that unreasonable (to all but the most devoted techies)? Because it's money. Whenever money is involved, people get real sensitive. Why don't people share the same concern about children? Like many other people I track my bank account on-line. I pay my bills on-line. I track my stock portfolio and make stock trades on-line. Millions of people do this. The school puts my kids' grades on-line along with all the other students in our school district. I actually like to be able to look at my kids grades any time of the day or night. This keeps me in the loop about how my kids are doing in school. I applaud the school district for doing this. If I had to call all seven of my kids' teachers every couple of weeks to find out how they are doing in each of their classes then this would be a full-time job in itself. I am more concerned about the paper that goes into my garbage than what people can find out about me on-line. I invested in a very good paper shredder and use it constantly. I once picked up some papers than had blown out of my neighbors trash can into my yard. To my surprise it was his bank statement. I am more concerned about the financial clerk that enters my donations into FIS. Once I had our financial clerk in a former ward mention to someone else in the ward (and not the bishop) the amount of a donation that I had made. I started paying my tithing directly to the church office rather than to my ward. Of course, the main reason I do this now is the fact I use stock (and other gifts in kind') to pay my tithing. In short, I have almost three degrees in computer engineering (I dropped out of my PhD program before I finished my dissertation to start a very successful internet company) and view myself as a very devoted techie. I don't find the idea of dealing with money on-line unreasonable. I don't find the idea of my kids' grades being posted on-line unreasonable. If the Church decided to put my donation information on-line to make my tax preparation easier then I would use that service as well. I find on-line services very useful as a responsible parent to do my job and to have more time with my family. IMHO, -stacey. ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss
Re: [Ldsoss] Scout Tracking
If I had to call all sevenof my kids' teachers every couple of weeks to find out how they aredoing in each of their classes then this would be a full-time job in itself.For the teacher, you mean!! Tom HAws ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss
Re: [Ldsoss] Scout Tracking
Personally, I would be fine with my finances on the web as well. I do all my banking online, so why not tithing? That said, I understand your point, and I agree that legally some opt-in would be needed, but I far fewer people care about online privacy than you might think. I must admit I have never understood why I should care what others know about me. I would honestly like to know what motivates you (or people in general) to care about keeping your finances or personal information secret? Are you concerned about identity theft? Kevin Steven H. McCown wrote: Actually, the only parents who are that out of the loop are those who either choose to be or don't concern themselves enough to ask. A little how's my son doing? to the Scoutmaster would give a better picture. Most Scout Masters are excited to talk with parents. Posting minor children's information to the internet and trying to secure it with software that isn't secure won't really cure that. As for the $40/year and writing a new software package, that's great, I support it. My only complaint is with posting minor children's information (as discussed on this list) to the web. Legally, the church will have to provide an opt-out mechanism (in several countries besides the US). People keep mentioning parental involvement and parental tracking. Here's a thought, it might be valuable for tithing payers to monitor their charitable donations and compare their records to the church's. If only FIS was online accessible (with appropriate security to only monitor ones own donations), then we could all go online with a great tool to assist in financial planning. This would ease a busy person's burdens and make it so they never had to go ask the ward clerk for a printout. Why is that unreasonable (to all but the most devoted techies)? Because it's money. Whenever money is involved, people get real sensitive. Why don't people share the same concern about children? Steve -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Stacey Sent: Thursday, August 31, 2006 10:39 AM To: LDS Open Source Software Subject: Re: [Ldsoss] Scout Tracking Steven H. McCown wrote: The key is that if you don't *really* have to be web-accessible, then don't. If it isn't web-accessible then parents continue to be largely out of the loop on their son's status in scouts and we continue to spend money out of our YM budgets for TroopMaster licenses. Why would we want to take the time to change to save about $40/yr? However, collectively with all the wards this could add up for the Church as a whole. We don't think collectively at the ward level, however. Therefore, $40/yr for scout tracking software can be easily budgeted for to save a headache. Each parent could have their own copy of the scout tracking software... Wrong. Installing and supporting an application on every parent's computer is impractical. We would end up fixing parent's operating system issues for the most part. Scout masters want to be scout masters and not software support specialist. IMHO, -stacey. ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss
Re: Re: [Ldsoss] Scout Tracking
Thanks to the student progress system
our school district is using I know if there is a problem with one of my
kids before the report cards come out. Also, teachers are not spending
a good deal of their time talking to the parents but rather they are
spending more of their time, well hopefully, teaching.
This is actually what concerns me about my daughter's school. She's a
first grader and they want to post her and her classmates' (w/ naive
parents permission, of course) pictures and names along with progress
info on a website, no login or anything to protect that info. It
scares me that any weirdo out there can then view my daughter's
picture, know her name, and what school she goes to. I think we are
often not careful enough about what we allow others to display on the
web.
If it were behind a password-protected site, then maybe it would be
another thing. Sorry - just ranting about a recent frustration with
the schools here in Utah.
Jesse
--
#!/usr/bin/perl
$^=q;@!~|{krwyn{u$$Sn||n|}j=$$Yn{uQjltn{ 0gFzD gD, 00Fz,
0,,( 0hF 0g)F/=, 0 L$/GEIFewe{,$/ 0C$~ @=,m,|,(e 0.), 01,pnn,y{
rw} ;,$0=q,$,,($_=$^)=~y,$/ C-~@=\n\r,-~$:-u/
#y,d,s,(\$.),$1,gee,print
___
Ldsoss mailing list
Ldsoss@lists.ldsoss.org
http://lists.ldsoss.org/mailman/listinfo/ldsoss
Re: [Ldsoss] Scout Tracking
Jesse Stay wrote: This is actually what concerns me about my daughter's school. She's a first grader and they want to post her and her classmates' (w/ naive parents permission, of course) pictures and names along with progress info on a website, no login or anything to protect that info. It scares me that any weirdo out there can then view my daughter's picture, know her name, and what school she goes to. I think we are often not careful enough about what we allow others to display on the web. If it were behind a password-protected site, then maybe it would be another thing. Sorry - just ranting about a recent frustration with the schools here in Utah. The school district here in Texas sends a letter out with the student ID number (used for the login name) and a randomly generated password. Everything is password protected. There are no pictures of students or even their name on the web site. Just their student ID number. Someone actually thought about this it seems or, maybe, they actually read some of the emails I sent. :) FYI, in case everyone didn't see this on slashdot... Ross Anderson's excellent security engineering book is now on-line: See http://www.cl.cam.ac.uk/~rja14/book.html or download the entire thing at: http://rapidshare.de/files/31139575/security_engineering.pdf.html http://www.filewire.com/download.php?id=5ead2cad1c6cb101e336dc0 http://www.zshare.net/download/security_engineering-pdf.html -stacey. ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss
RE: [Ldsoss] Scout Tracking
There are some more serious security implications with your choice of tools (e.g., injections). Far from the definitive word, these are hotly debated, demonstrated, and refuted. Here are a couple of blog articles that you should research and consider re PHP: - PHP Insecurity: Failure of Leadership (http://www.greebo.net/?p=320) - PHP Security: Dumb Users or Dumb APIs? (http://www.sitepoint.com/blogs/2006/01/24/php-security-dumb-users-or-dumb-apis/) This is from last years Blackhat, but its fairly new and still relevant: - Beefed up OWASP 2.0 introduced at BlackHat (http://searchsecurity.techtarget.com/originalContent/0,289142,sid14_gci443,00.html) and (http://www.owasp.org/index.php/Main_Page) How to harden this? Its a moving target. PHP6? Until it is released and then Ill say PHP7 ;-) The key is that if you dont *really* have to be web-accessible, then dont. Steve From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Oscar Schultz Sent: Friday, August 18, 2006 5:48 PM To: [EMAIL PROTECTED]; LDS Open Source Software Subject: Re: [Ldsoss] Scout Tracking you ever get the table definitions done as SQL? Hello list, Between scout camp, yw camp and family reunions I done some but not as much as I wanted to the tracker. Below is what I currently have The question for the list is how to make the user interface secure. The tools I have selected are mysql, php5, pear, apache2, and linux as the base os. The application will run as a web server (server side code rather than _javascript_) and will require cookies. I have been reading about cross-side script attacks (xss). xss looks to be a serious problem since it uses man in the middle to steal cookies. Anyone have some ideas how to harden a web application so I can avoid design problems upfront. thanks oscar create database tracker; grant create,alter,select,insert,update,delete on tracker.* to [EMAIL PROTECTED] use tracker; #the table to record personal information create table people ( record_id int(32) unsigned auto_increment, firstname varchar (30) not null default '', middlename varchar (30) not null default '', lastname varchar (30) not null default '', preferredname varchar (30) not null default '', gender varchar (1), birthdate varchar (2), birthmonth varchar (3), birthyear varchar (4), emergency_passphrase varchar (30), date ); # the table to record personal address information # 1 people record to many address record relationship create table address ( record_id int(32) unsigned auto_increment, people_record_id int(32) unsigned auto_increment, address1 varchar (40), address2 varchar (40), city varchar (40), county varchar (40), state varchar (40), zipcode varchar (9), type varchar (10), # (primary, secondary, mailbox, residence, shipping, other, unknown) date ? ); # the table to record personal phone information # 1 people record to many phone record relationship create table phone ( record_id int (32) unsigned auto_increment, people_record_id int(32) unsigned auto_increment, type varchar (10), # (personal cell, home, business, home2, business cell) area_code varchar (3), number varchar (7), extension varchar (7). date ?. ); # a table to record emergency contacts # 1 personal to many personal relationship create table emergency_contact record_id int (32) unsigned auto_increment, people_record_id int (32) unsigned, #(participate) people_record_id int (32) unsigned, #(emergency contact) relationship varchar (32), # string date ? ); # the authorization table to control access via the # web interface create table auth ( record_id int (32) unsigned auto_increment, fname, #first_name mname, #middle_name lname, #last_name userid, password, password2, auth_level, email, password_start_date, password_status, date ? ); # a table to record the high level in the hierarchy # of the award requirement, subrequirement chain create table awards ( record_id int (32) unsigned auto_increment, name varchar (128), #the name of the award org_group int (32) unsigned, # link to the group record max_age int (2) unsigned, # max age the award can be obtained min_age int (2) unsigned, # minimum age for award date ? ); # a table to record each completed award # many awards to 1 people relationship create table completed_awards ( record_id int (32) unsigned auto_increment, people_record_id int (32) unsigned auto_increment, award_record_id int (32) unsigned auto_increment, date_completed varchar (9), #ddmmm ); # a table to record which image file relates to which person # each file is a scanned image of the medical form create table medical_form ( record_id int (32) unsigned auto_increment, people_record_id int (32) unsigned auto_increment, image_record_id int (32) unsigned auto_increment, date ? ); # a table to record which image file related to which person # and event Each image
Re: [Ldsoss] Scout Tracking
Steven H. McCown wrote: The key is that if you don’t *really* have to be web-accessible, then don’t. If it isn't web-accessible then parents continue to be largely out of the loop on their son's status in scouts and we continue to spend money out of our YM budgets for TroopMaster licenses. Why would we want to take the time to change to save about $40/yr? However, collectively with all the wards this could add up for the Church as a whole. We don't think collectively at the ward level, however. Therefore, $40/yr for scout tracking software can be easily budgeted for to save a headache. Each parent could have their own copy of the scout tracking software... Wrong. Installing and supporting an application on every parent's computer is impractical. We would end up fixing parent's operating system issues for the most part. Scout masters want to be scout masters and not software support specialist. IMHO, -stacey. ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss
Re: [Ldsoss] Scout Tracking - security
I agree with Paul. Keep moving forward Oscar! Tom Paul Penrod wrote: Oscar, There is an old saying in business: If you want to stagnate a company, give control of it to an Accountant. If you want to kill it, give control of it to a lawyer. The point is simply this: Instead of worrying about the theoretical, do what you are doing and when you are done, people can fork the code and port it for the paranoid - or whomever. Your work has value. Don't forget that. And, you are actually doing something - not sitting back pontificating from afar. One other side comment: I've been knocking around this business since the late 70's and having worked with people from Bell Labs and other notable places, I can assure you there is no such thing as a secure language. You just have to select good tools for the job; ones you are comfortable and competent in, and move forward. ..Paul Oscar Schultz wrote: After reviewing the urls (the ones that are valid) I did not see anything to suggest php is any worse or better than any other language. My number one choice would be to use "c". The app should support winxx, mac, unix, linux and text (if possible). The app also must scale from localhost to intranet to internet. The app must also scale from a few users up to several hundred or more concurrent users. Security of data is more important than speed or user ease of use. The app should also require the minimum software installs on the user's machine and add no additional security risks for the users. As I have reviewed the various requirements and options basing app on the web is the best option I see. Feel free to make your suggestions. My Langauges - c, c++, bash, perl, php, assembler, fortran, pascal, cobal. I gave up trying to learn java - I just do not have that much time to spend. Python - it is a great language but counting columns is something I don't do anymore - too much fortran, assembler, and cobol. Maybe next time. That leaves php or perl unless someone knows some really cool c and c++ tricks. That still leaves the problem of how to secure the app and make some of the user information persistant - no one wants to enter their userid and password on every form. Cookies and hidden data fields seem to be the only real option. What are the other options? I have considered having one user enter the data and a second confirm the data. Right now cookies still look like the best option. thanks for the help and comments oscar On Saturday 19 August 2006 11:20 am, Steven H. McCown wrote: I'm resending this since it bounced. Something about being over 40KB. There are some more serious security implications with your choice of tools (e.g., injections). Far from the definitive word, these are hotly debated, demonstrated, and refuted. Here are a couple of blog articles that you should research and consider re PHP: - PHP Insecurity: Failure of Leadership (http://www.greebo.net/?p=320) - PHP Security: Dumb Users or Dumb APIs? (http://www.sitepoint.com/blogs/2006/01/24/php-security-dumb-users-or-dumb- a pis/) This is from last year's Blackhat, but it's fairly new and still relevant: - Beefed up OWASP 2.0 introduced at BlackHat (http://searchsecurity.techtarget.com/originalContent/0,289142,sid14_gci111 1 443,00.html) and (http://www.owasp.org/index.php/Main_Page) How to harden this? It's a moving target. PHP6? Until it is released and then I'll say PHP7. ;-) The key is that if you don't *really* have to be web-accessible, then don't. Steve ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss -- Tom Welch [EMAIL PROTECTED] (801) 240-1609 (858) 829-4614 - Cell --
Re: [Ldsoss] Scout Tracking - security
After reviewing the urls (the ones that are valid) I did not see anything to suggest php is any worse or better than any other language. My number one choice would be to use c. The app should support winxx, mac, unix, linux and text (if possible). The app also must scale from localhost to intranet to internet. The app must also scale from a few users up to several hundred or more concurrent users. Security of data is more important than speed or user ease of use. The app should also require the minimum software installs on the user's machine and add no additional security risks for the users. As I have reviewed the various requirements and options basing app on the web is the best option I see. Feel free to make your suggestions. My Langauges - c, c++, bash, perl, php, assembler, fortran, pascal, cobal. I gave up trying to learn java - I just do not have that much time to spend. Python - it is a great language but counting columns is something I don't do anymore - too much fortran, assembler, and cobol. Maybe next time. That leaves php or perl unless someone knows some really cool c and c++ tricks. That still leaves the problem of how to secure the app and make some of the user information persistant - no one wants to enter their userid and password on every form. Cookies and hidden data fields seem to be the only real option. What are the other options? I have considered having one user enter the data and a second confirm the data. Right now cookies still look like the best option. thanks for the help and comments oscar On Saturday 19 August 2006 11:20 am, Steven H. McCown wrote: I'm resending this since it bounced. Something about being over 40KB. There are some more serious security implications with your choice of tools (e.g., injections). Far from the definitive word, these are hotly debated, demonstrated, and refuted. Here are a couple of blog articles that you should research and consider re PHP: - PHP Insecurity: Failure of Leadership (http://www.greebo.net/?p=320) - PHP Security: Dumb Users or Dumb APIs? (http://www.sitepoint.com/blogs/2006/01/24/php-security-dumb-users-or-dumb- a pis/) This is from last year's Blackhat, but it's fairly new and still relevant: - Beefed up OWASP 2.0 introduced at BlackHat (http://searchsecurity.techtarget.com/originalContent/0,289142,sid14_gci111 1 443,00.html) and (http://www.owasp.org/index.php/Main_Page) How to harden this? It's a moving target. PHP6? Until it is released and then I'll say PHP7. ;-) The key is that if you don't *really* have to be web-accessible, then don't. Steve ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss
Re: [Ldsoss] Scout Tracking - security
Oscar, There is an old saying in business: If you want to stagnate a company, give control of it to an Accountant. If you want to kill it, give control of it to a lawyer. The point is simply this: Instead of worrying about the theoretical, do what you are doing and when you are done, people can fork the code and port it for the paranoid - or whomever. Your work has value. Don't forget that. And, you are actually doing something - not sitting back pontificating from afar. One other side comment: I've been knocking around this business since the late 70's and having worked with people from Bell Labs and other notable places, I can assure you there is no such thing as a secure language. You just have to select good tools for the job; ones you are comfortable and competent in, and move forward. ...Paul Oscar Schultz wrote: After reviewing the urls (the ones that are valid) I did not see anything to suggest php is any worse or better than any other language. My number one choice would be to use "c". The app should support winxx, mac, unix, linux and text (if possible). The app also must scale from localhost to intranet to internet. The app must also scale from a few users up to several hundred or more concurrent users. Security of data is more important than speed or user ease of use. The app should also require the minimum software installs on the user's machine and add no additional security risks for the users. As I have reviewed the various requirements and options basing app on the web is the best option I see. Feel free to make your suggestions. My Langauges - c, c++, bash, perl, php, assembler, fortran, pascal, cobal. I gave up trying to learn java - I just do not have that much time to spend. Python - it is a great language but counting columns is something I don't do anymore - too much fortran, assembler, and cobol. Maybe next time. That leaves php or perl unless someone knows some really cool c and c++ tricks. That still leaves the problem of how to secure the app and make some of the user information persistant - no one wants to enter their userid and password on every form. Cookies and hidden data fields seem to be the only real option. What are the other options? I have considered having one user enter the data and a second confirm the data. Right now cookies still look like the best option. thanks for the help and comments oscar On Saturday 19 August 2006 11:20 am, Steven H. McCown wrote: I'm resending this since it bounced. Something about being over 40KB. There are some more serious security implications with your choice of tools (e.g., injections). Far from the definitive word, these are hotly debated, demonstrated, and refuted. Here are a couple of blog articles that you should research and consider re PHP: - PHP Insecurity: Failure of Leadership (http://www.greebo.net/?p=320) - PHP Security: Dumb Users or Dumb APIs? (http://www.sitepoint.com/blogs/2006/01/24/php-security-dumb-users-or-dumb- a pis/) This is from last year's Blackhat, but it's fairly new and still relevant: - Beefed up OWASP 2.0 introduced at BlackHat (http://searchsecurity.techtarget.com/originalContent/0,289142,sid14_gci111 1 443,00.html) and (http://www.owasp.org/index.php/Main_Page) How to harden this? It's a moving target. PHP6? Until it is released and then I'll say PHP7. ;-) The key is that if you don't *really* have to be web-accessible, then don't. Steve ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss
RE: [Ldsoss] Scout Tracking
Im resending this since it bounced. Something about being over 40KB There are some more serious security implications with your choice of tools (e.g., injections). Far from the definitive word, these are hotly debated, demonstrated, and refuted. Here are a couple of blog articles that you should research and consider re PHP: - PHP Insecurity: Failure of Leadership (http://www.greebo.net/?p=320) - PHP Security: Dumb Users or Dumb APIs? (http://www.sitepoint.com/blogs/2006/01/24/php-security-dumb-users-or-dumb-apis/) This is from last years Blackhat, but its fairly new and still relevant: - Beefed up OWASP 2.0 introduced at BlackHat (http://searchsecurity.techtarget.com/originalContent/0,289142,sid14_gci443,00.html) and (http://www.owasp.org/index.php/Main_Page) How to harden this? Its a moving target. PHP6? Until it is released and then Ill say PHP7 ;-) The key is that if you dont *really* have to be web-accessible, then dont. Steve ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss
Re: [Ldsoss] Scout Tracking
On Tuesday 15 August 2006 8:24 pm, A. Rick Anderson wrote: Oscar Schultz wrote: On Monday 10 July 2006 10:04 am, Tom Welch wrote: Good start Oscar. It is a start. I'll add the changes, modify into sql and repost. Did you ever get the table definitions done as SQL? Hello list, Between scout camp, yw camp and family reunions I done some but not as much as I wanted to the tracker. Below is what I currently have The question for the list is how to make the user interface secure. The tools I have selected are mysql, php5, pear, apache2, and linux as the base os. The application will run as a web server (server side code rather than _javascript_) and will require cookies. I have been reading about cross-side script attacks (xss). xss looks to be a serious problem since it uses man in the middle to steal cookies. Anyone have some ideas how to harden a web application so I can avoid design problems upfront. thanks oscar create database tracker; grant create,alter,select,insert,update,delete on tracker.* to [EMAIL PROTECTED] use tracker; #the table to record personal information create table people ( record_id int(32) unsigned auto_increment, firstname varchar (30) not null default '', middlename varchar (30) not null default '', lastname varchar (30) not null default '', preferredname varchar (30) not null default '', gender varchar (1), birthdate varchar (2), birthmonth varchar (3), birthyear varchar (4), emergency_passphrase varchar (30), date ); # the table to record personal address information # 1 people record to many address record relationship create table address ( record_id int(32) unsigned auto_increment, people_record_id int(32) unsigned auto_increment, address1 varchar (40), address2 varchar (40), city varchar (40), county varchar (40), state varchar (40), zipcode varchar (9), type varchar (10), # (primary, secondary, mailbox, residence, shipping, other, unknown) date ? ); # the table to record personal phone information # 1 people record to many phone record relationship create table phone ( record_id int (32) unsigned auto_increment, people_record_id int(32) unsigned auto_increment, type varchar (10), # (personal cell, home, business, home2, business cell) area_code varchar (3), number varchar (7), extension varchar (7). date ?. ); # a table to record emergency contacts # 1 personal to many personal relationship create table emergency_contact record_id int (32) unsigned auto_increment, people_record_id int (32) unsigned, #(participate) people_record_id int (32) unsigned, #(emergency contact) relationship varchar (32), # string date ? ); # the authorization table to control access via the # web interface create table auth ( record_id int (32) unsigned auto_increment, fname, #first_name mname, #middle_name lname, #last_name userid, password, password2, auth_level, email, password_start_date, password_status, date ? ); # a table to record the high level in the hierarchy # of the award requirement, subrequirement chain create table awards ( record_id int (32) unsigned auto_increment, name varchar (128), #the name of the award org_group int (32) unsigned, # link to the group record max_age int (2) unsigned,# max age the award can be obtained min_age int (2) unsigned,# minimum age for award date ? ); # a table to record each completed award # many awards to 1 people relationship create table completed_awards ( record_id int (32) unsigned auto_increment, people_record_id int (32) unsigned auto_increment, award_record_id int (32) unsigned auto_increment, date_completed varchar (9), #ddmmm ); # a table to record which image file relates to which person # each file is a scanned image of the medical form create table medical_form ( record_id int (32) unsigned auto_increment, people_record_id int (32) unsigned auto_increment, image_record_id int (32) unsigned auto_increment, date ? ); # a table to record which image file related to which person # and event Each image is a scan of the completed doc # many permissions to 1 person relationship create table permission_form ( record_id int (32) unsigned auto_increment, people_record_id int (32) unsigned auto_increment, event_record_id int (32) unsigned auto_increment, image_record_id int (32) unsigned auto_increment, date ? ); # a table to relate people to pictures # many to many relationship create table picture_people ( record_id int (32) unsigned auto_increment, people_record_id int (32) unsigned auto_increment, picture_record_id int (32) unsigned auto_increment ); # a table to record each picture and metadata
Re: [Ldsoss] Scout Tracking
Oscar Schultz wrote: On Monday 10 July 2006 10:04 am, Tom Welch wrote: Good start Oscar. It is a start. I'll add the changes, modify into sql and repost. Did you ever get the table definitions done as SQL? -- A. Rick Anderson ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss
Re: [Ldsoss] Scout Tracking
On Monday 10 July 2006 10:04 am, Tom Welch wrote: I've used Dia in the past for Linux. I've not used Umbrello but it looks like it should do the trick just fine. Also, to model the data, have you given MySQL Workbench http://dev.mysql.com/downloads/workbench/1.0.html a try? thanks - I will try dia. gety Here are my comments on your data table. Take them for what they are worth...about a nickel and two pennies. * As a general note: If you want to allow for synchronization between a local system and a remote system then all of your primary keys should be in the form of a guid (I use varchar(32)). Most DB's have an auto-increment type for ints and these are used as primary keys but you can't synchronize as easily .. especially if you are allowing for a multi-user system because two keys could get the same value. If your is not to allow for synchronization then I'd let the DB handle the auto-assigning of the primary key. my plan is to use a varchar field as a membership number - good catch - I completely forgot a variable I can use as a common number between dbs. I have been planning to use the record_id as only a local number and to use the auto-increment feature for all the record_ids . The system will be multi-user. * On the people_table, why do you have birthdate and also birthmonth, birthyear and date. It seems that birthdate would handle it and any programming language you use could extract the month/year easily. the date field in each field is to doc when a record was created - that permits versions . I am not sure why I felt the need to doc creation dates. I think the date field will be used to document changes, track other info to prevent complains about data errors. * On the address_table, what is the date field for? Also do we think that we will have multiple addresses for people and so need to keep a separate table for them? I agree if this is to be expected then it would be more efficient to have the addresses in a separate table. Multiple addresses - sure . we have youth living in multiple homes (divorce, boarding schools, etc ), unlisted addresses (shipping address, po box) and other situations. * What is the date field on the phone_table used for? In fact, all tables have a date field. I'm not sure their purpose. I just want to know how old a phone number is - people change phone number every day AND without telling me. If I know how old the number is and what type it is (cell, landline) I can guess the probability of finding a good number when someone has multiple phone numbers * On the Emergency Contact section, I can see that you intend to have a small link table linking boys to their parents or other contacts. My comment here is that it may be a bit of overkill to force the user to enter in all parents and other people that act as emergency contact information into the DB. What I mean is that if I enter in a boy's information (address, phone number, etc) I then have to enter in the same information for his parents so that I can link the boy to the parent. What you end up with is two records with basically the same information. It may be more efficient to create a family table which would consist of the last name of the family and then the address, phone numbers, etc. Then have a family members table which you enter in family members (first name, birthdates, etc). This way you are not double or triple entering in the address. emergency contacts are not always the parents . I also need to add an emergency release passphrase to permit someone to gain emergency guardianship of a youth. * On the authorization_table, why do you have two password fields? You will need to ask for the user to enter in the password twice but that is to just verify that it is entered in correctly. I have the 2 fields to allow the use of a 2 stage password. the 2 stage is not required - it is just available * On the authorization_table, I recommend that you lose the userid and use the email address to verify and allow the user to login. emails change and can be extracted from mailing lists. Using a userid is just a way to obsure part of the info needed to login. * On the Image and Picture tables, would it make more sense to store the data in a blob in the DB instead of having a link to a file? Links are easily broken. I prefer to store images as files - I still do not trust databases as much as I trust filesystems. Also keeping the images as non-blobs keeps the database smaller and allows access to the images with multiple tools (outside of the database). Broken links can be recovered if the pathname/filename naming convention has enough info. Good start Oscar. It is a start. I'll
Re: [Ldsoss] Scout Tracking
I've used Dia in the past for Linux. I've not used Umbrello but it looks like it should do the trick just fine. Also, to model the data, have you given MySQL Workbench a try? Here are my comments on your data table. Take them for what they are worth...about a nickel and two pennies. As a general note: If you want to allow for synchronization between a local system and a remote system then all of your primary keys should be in the form of a guid (I use varchar(32)). Most DB's have an auto-increment type for ints and these are used as primary keys but you can't synchronize as easily .. especially if you are allowing for a multi-user system because two keys could get the same value. If your is not to allow for synchronization then I'd let the DB handle the auto-assigning of the primary key. On the "people_table", why do you have "birthdate" and also "birthmonth", "birthyear" and "date". It seems that "birthdate" would handle it and any programming language you use could extract the month/year easily. On the "address_table", what is the "date" field for? Also do we think that we will have multiple addresses for people and so need to keep a separate table for them? I agree if this is to be expected then it would be more efficient to have the addresses in a separate table. What is the date field on the "phone_table" used for? In fact, all tables have a "date" field. I'm not sure their purpose. On the "Emergency Contact" section, I can see that you intend to have a small link table linking "boys" to their parents or other contacts. My comment here is that it may be a bit of "overkill" to force the user to enter in all parents and other people that act as emergency contact information into the DB. What I mean is that if I enter in a boy's information (address, phone number, etc) I then have to enter in the same information for his parents so that I can link the boy to the parent. What you end up with is two records with basically the same information. It may be more efficient to create a "family" table which would consist of the last name of the family and then the address, phone numbers, etc. Then have a "family members" table which you enter in family members (first name, birthdates, etc). This way you are not double or triple entering in the address. On the "authorization_table", why do you have two password fields? You will need to ask for the user to enter in the password twice but that is to just verify that it is entered in correctly. On the "authorization_table", I recommend that you lose the "userid" and use the email address to verify and allow the user to login. On the Image and Picture tables, would it make more sense to store the data in a blob in the DB instead of having a link to a file? Links are easily broken. Good start Oscar. Tom Oscar Schultz wrote: Hopefully someone on the list has reviewed my set of tables and fields. no responses about the structure yet. I need a list of the needed basic functions to produce a tracker with a minimum set of functions . A set of functions to manage (add,delete, modify) people, events, awards, requirements, and produce a set of reports is what I think are needed . Additionally a set of functions to manage access to the program data. Any linux fans out there have a favorite tool to design the application. I'm looking for a good tool to flow-chart with and to do the initial design work of the app. I have looked at using umbrello to doc/flowchart the app . Suggestions are appreciated . I also plan to use sane and subversion, to extend what I can write to include scanning and image/picture version tracking . thanks oscar On Friday 07 July 2006 10:44 pm, Oscar Schultz wrote: I have spent some time attempting to setup a sql database and tables as the basis for my version of the tracking software. Hopefully those database admins out there can review my table outline for missing fields and/or crazy table relationships and make some helpful comments. enjoy and thanks oscar #the table to record personal information people_table record_id firstname middlename lastname preferredname gender birthdate birthmonth birthyear date # the table to record personal address information # 1 people record to many address record relationship address_table record_id people_record_id address1 address2 city county state zipcode type (primary, secondary, mailbox, residence, shipping, other, unknown) date # the table to record personal phone information # 1 people record to many phone record relationship phone_table record_id people_record_id type (personal cell, home, business, home2, business cell) number date # a table to record emergency contacts # 1 personal to many personal relationship emergency_contact_table record_id people_record_id (participate) people_record_id (emergency contact) relationship date # the authorization table to control access via the # web interface authorization_table record_id
Re: [Ldsoss] Scout Tracking
Tom Welch wrote: I've used Dia in the past for Linux. I've not used Umbrello but it looks like it should do the trick just fine I used Umbrello briefly once. As I recall, it worked reasonably well for drawing, but I didn't care for its round-trip code-generation. Unless you are doing sequence diagrams, or generating code, my experience has been that CASE tools aren't worth the hassle. Visio or Dia works just as well. * As a general note: If you want to allow for synchronization between a local system and a remote system then all of your primary keys should be in the form of a guid (I use varchar(32)). Most DB's have an auto-increment type for ints and these are used as primary keys but you can't synchronize as easily .. especially if you are allowing for a multi-user system because two keys could get the same value. If your is not to allow for synchronization then I'd let the DB handle the auto-assigning of the primary key. There was a previous link to GUID's and UUID's in an earlier discussion that pointed to Wikipedia. Any system that wants to support synchronization should probably use some form of GUID. * On the address_table, what is the date field for? Also do we think that we will have multiple addresses for people and so need to keep a separate table for them? I agree if this is to be expected then it would be more efficient to have the addresses in a separate table. With all the devorces, multiple addresses actually makes sense. However, to avoid burdening everyone with multiple addresses, you might define a set of primary address fields. * What is the date field on the phone_table used for? In fact, all tables have a date field. I'm not sure their purpose. * On the Emergency Contact section, I can see that you intend to have a small link table linking boys to their parents or other contacts. My comment here is that it may be a bit of overkill to force the user to enter in all parents and other people that act as emergency contact information into the DB. What I mean is that if I enter in a boy's information (address, phone number, etc) I then have to enter in the same information for his parents so that I can link the boy to the parent. What you end up with is two records with basically the same information. It may be more efficient to create a family table which would consist of the last name of the family and then the address, phone numbers, etc. Then have a family members table which you enter in family members (first name, birthdates, etc). This way you are not double or triple entering in the address. To be PC, I'd suggest calling this a Household and you possible might want to define one or more Head of Household. * On the authorization_table, I recommend that you lose the userid and use the email address to verify and allow the user to login. I hate it when sites do this. You are presuming (a) a person's email is fixed for life, (b) that ISP's don't reissue email addresses. Neither of these conditions are assured. One of my original ISP's re-issued my email address to someone else within a few months of my dropping the account. IMHO, email address should no more be used for a userid then a street address. * On the Image and Picture tables, would it make more sense to store the data in a blob in the DB instead of having a link to a file? Links are easily broken. Also, file links tend to interfere with data portabilility. Good start Oscar. I'm not a fan of PHP, but databases are universal :-) Also, going with a web application will usually facilitate a n-tier application approach, so even if the user stages it entirely on one box, the application will have been designed so that it can later be scaled. Putting a fat client on a web application is much easier then refactoring a desktop application or a client-server application. -- A. Rick Anderson ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss
Re: [Ldsoss] Scout Tracking
Hopefully someone on the list has reviewed my set of tables and fields. no responses about the structure yet. I need a list of the needed basic functions to produce a tracker with a minimum set of functions . A set of functions to manage (add,delete, modify) people, events, awards, requirements, and produce a set of reports is what I think are needed . Additionally a set of functions to manage access to the program data. Any linux fans out there have a favorite tool to design the application. I'm looking for a good tool to flow-chart with and to do the initial design work of the app. I have looked at using umbrello to doc/flowchart the app . Suggestions are appreciated . I also plan to use sane and subversion, to extend what I can write to include scanning and image/picture version tracking . thanks oscar On Friday 07 July 2006 10:44 pm, Oscar Schultz wrote: I have spent some time attempting to setup a sql database and tables as the basis for my version of the tracking software. Hopefully those database admins out there can review my table outline for missing fields and/or crazy table relationships and make some helpful comments. enjoy and thanks oscar #the table to record personal information people_table record_id firstname middlename lastname preferredname gender birthdate birthmonth birthyear date # the table to record personal address information # 1 people record to many address record relationship address_table record_id people_record_id address1 address2 city county state zipcode type (primary, secondary, mailbox, residence, shipping, other, unknown) date # the table to record personal phone information # 1 people record to many phone record relationship phone_table record_id people_record_id type (personal cell, home, business, home2, business cell) number date # a table to record emergency contacts # 1 personal to many personal relationship emergency_contact_table record_id people_record_id (participate) people_record_id (emergency contact) relationship date # the authorization table to control access via the # web interface authorization_table record_id first_name middle_name last_name userid password password2 auth_level email password_start_date password_status date # a table to record the high level in the hierarchy # of the award requirement, subrequirement chain award_table record_id name type (LDS,BSA,other) level (youth(deacon,teacher,priest,scout,cub,varsity,venture,adult) max_age min_age date # a table to record each completed award # many awards to 1 people relationship completed_awards_table record_id people_record_id award_record_id date_completed # a table to record which image file relates to which person # each file is a scanned image of the medical form medical_form_table record_id people_record_id image_record_id date # a table to record which image file related to which person # and event Each image is a scan of the completed doc # many permissions to 1 person relationship permission_form_table record_id people_record_id event_record_id image_record_id date # a table to relate people to pictures # many to many relationship picture_people_table record_id people_record_id picture_record_id # a table to record each picture and metadata about the picture picture_table record_id date_of_picture location description filename # a table to record each scanned image/doc # 1 people to many images relationship image_table record_id filename image_date description image_owner_people_record_id # a table to record event information for calandaring event_table record_id event_start_date event_end_date description group (miamaids, bears, scout, priest etc) ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss
Re: [Ldsoss] Scout Tracking
Steven H. McCown wrote: Since the requirement/goal/whatever was that the software be accessible to all church users and non-church users, shouldn't the platform and tools choice reflect *their preferences*??? Later, yes. Now, not necessarily. Let developers use what they will. I suspect you're overestimating the difficulty of creating a point-n-click installer. Even if the most successful implementation turns out to be a PHP one, I don't doubt that someone will figure out all of the details to make a truly simple point-n-click Windows installer. To use another cliche, I think you're putting the cart before the horse. Shane ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss
RE: [Ldsoss] Scout Tracking
Since I didn't state my preferred opinion, you don't really know whether the stated tools are or are not my favorite. I intentionally didn't discuss that, because I didn't want to have a 'personal favorites' discussion. The real point of my post was that the #1 requirement stated for this type of project is that it be open source. The proposed solution fully meets the requirement. The #2 requirement stated was that the application be accessible to everyone. That's the whole point of my post. In choosing the tools/environment that were chosen, this requirement was completely set aside. An estimated 90% of home users do not use Linux. Even though MySQL is available under Windows, most users will not want to install and maintain it. Someone recommended an embedded database such as Derby. That would take away the need for the user to be aware of and run database system software. Someone else mentioned that Java was supporting embedded databases natively in the upcoming version. So why does any of this matter? OSS'ers typically write code out of personal interest or a hobby. This is wonderful. They also use the tools that they know or more likely *prefer*. Since the requirement/goal/whatever was that the software be accessible to all church users and non-church users, shouldn't the platform and tools choice reflect *their preferences*??? Shouldn't we go where the users are? Where they are likely to be? What are they more likely to use? What are their tolerances? There's a tired old cliché about a guy who lost some money and was looking for it under a lamp post instead of where he lost it, as it was easier to see under the light. It seems to me that if the goal is to reach all potential users, then the choice of tools and platform should consider their needs and preferences -- not, necessarily, the developers. If the goal is to fulfill personal satisfaction through completing a project and hopefully help a few others in the process, then choosing whatever method is great. If the goal is to reach the largest number of Scout Leaders, then perhaps their needs should be considered a bit. The 'best' technology isn't always the best for the user... Steve -Original Message- From: Charles Fry [mailto:[EMAIL PROTECTED] Sent: Friday, July 07, 2006 8:33 AM To: [EMAIL PROTECTED]; LDS Open Source Software Subject: Re: [Ldsoss] Scout Tracking But why does any of this matter, Steven? I don't see why so many get so blocked up at the prospect of a project that doesn't conform to their personal preferences. Even if you are right (which is irrelevant for this argument), what will it hurt for this project to be pushed to completion? That would certainly be better than the current state where all that has happened is talk about perfect solutions. If someone wants a Windows app, they should go write one. If they want a web app, they should go write one. One doesn't preclude the other. In the end they might even find ways to get along. If anyone has sufficient desire and energy to create it, that is already justification enough to move forward. And who doesn't benefit from some healthy competition? We already have both PAF and PhpGedView; Linux, BSD, and Hurd; Thunderbird, Evolution, and SquirrelMail; mutt and pine; vi and emacs (cringe); Eclipse and NetBeans. The list goes on and on and on. I welcome diversity in LDS software. I think we need a lot more of it, even if it isn't perfect. Even if it doesn't meet everyone's needs. With time some projects may become more dominant than others, some may attract more developers, and some may become officially sanctioned by the Church. But while we wait to see what happens, we should be littering the web with projects, rather than waiting for the millennium before we finally start our first one. Charles ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss
RE: [Ldsoss] Scout Tracking
On 8 Jul 2006 at 8:08, Steven H. McCown wrote: Since the requirement/goal/whatever was that the software be accessible to all church users and non-church users, shouldn't the platform and tools choice reflect *their preferences*??? Shouldn't we go where the users are? Where they are likely to be? What are they more likely to use? What are their tolerances? This is the same tired argument for why so many people use Windows, because that is where the applications are. Well, if the applications that people want were on Linux, then the users would be there also. If the application is written as a hosted web app, it really doesn't matter what platform the end user has as long as it has a browser and net access. I have no doubt that there are plenty of people out there (me included) who would be happy to host it for our units, and likely other units, if the Church doesn't. --Richard ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss
RE: [Ldsoss] Scout Tracking
You're probably right. Scout Tracker will be the exact reason that a 50 year old, very busy, non-computer expert will delete Windows and rush out and by Linux. It will probably be an easy switch for him... Forgive me for unnecessary thinking about the user, I stand corrected Steve -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Richard Pyne Sent: Saturday, July 08, 2006 12:57 PM To: LDS Open Source Software Subject: RE: [Ldsoss] Scout Tracking On 8 Jul 2006 at 8:08, Steven H. McCown wrote: Since the requirement/goal/whatever was that the software be accessible to all church users and non-church users, shouldn't the platform and tools choice reflect *their preferences*??? Shouldn't we go where the users are? Where they are likely to be? What are they more likely to use? What are their tolerances? This is the same tired argument for why so many people use Windows, because that is where the applications are. Well, if the applications that people want were on Linux, then the users would be there also. If the application is written as a hosted web app, it really doesn't matter what platform the end user has as long as it has a browser and net access. I have no doubt that there are plenty of people out there (me included) who would be happy to host it for our units, and likely other units, if the Church doesn't. --Richard ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss
Re: [Ldsoss] Scout Tracking
On 7/6/06, Oscar Schultz [EMAIL PROTECTED] wrote: snip mine first_name middle_name last_name preferred_name gender birth_day birth_month birth_year record_id date_recorded It will all go into a sql table Address, phone, email will be separate tables since people can have multiple of each. My plan is to use either MySQL or PostGRES, php, apache, and linux with a web interface. My list of tables: people, addresses, phones, emails, events, attendance, awards, requirements, images, pictures, completed_awards, completed_requirements, emergency_contacts, medical_forms, and permission_slips should be interesting Be careful with some of this information; are you planning on storing medical information or just a flag saying they have turned in the medical form? Storing medical information would probably be a bad idea. slide ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss
RE: [Ldsoss] Scout Tracking
Your code (the snippet that I saw) looks fine, your tools sound, but you seem to not be concerned with marketing / user aspects. Most that use Linux will have MySQL, Postgres, PHP, and Apache. However, that is still less than 10% of the home user market (real computer geeks aside). While the server market has a much higher Linux adoption rate, the home PC market does not. Very few church buildings do not run Linux as they need to run MIS and such. Very few buildings have open internet connections, as well. So who is your customer? If you're just doing this for your own purposes or for a few other interested people, then you're on the right track. If you want this to be adopted as a widely-used program for Scouting, then you've put up some technological barriers that will preclude interested users from participating. The most successful and widely used apps (by home users) are Windows apps with an easy installation process. Also, standalone executable apps are predominant in this world. Java is kind of borderline, but the JRE can be insulated from the user. Users have chosen compiled .exe's, because they don't want to maintain an interpretive environment -- unless it's really insulated and automatically updated. Users nearly always choose simple over better -- think WinZip over 7-Zip (which I like, btw). The thread describing Windows users as somewhat half-witted was abrasive, but grounded in reality. Windows users just their apps to work -- they don't want to 'fiddle with it'. They don't care what language or tech is used to create an app, rather they just want to install it and forget about it and they don't want to have to maintain other tools like Perl or Python. The JRE seems to have crossed that barrier for other reasons. ***I am not criticizing technology or anyone's preference.*** I'm only criticizing a bit so that you don't get done and have everyone still having to pay for Scout tracking software, because they wanted a familiar and simple platform/environment. The question that I'm driving at is whether you're architecting towards a technological solution that you prefer (or that you consider better) or a user-required solution that end users are likely to use .? Steve -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Oscar Schultz Sent: Thursday, July 06, 2006 11:03 PM To: LDS Open Source Software Subject: Re: [Ldsoss] Scout Tracking ... My plan is to use either MySQL or PostGRES, php, apache, and linux with a web interface. ... ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss
Re: [Ldsoss] Scout Tracking
True - storing data/forms is challenging. Tracking awards makes planning and program management easier. Access to information however is required for trips. The required documentation for an outing to occur is: a permission slip per person, a required medical form (normally a class 2) per person, a valid trip permit, and the safe scouting guide. If the group is split into multiple vehicles/groups each adult group leader should have a copy. To prevent document loss normally copies at home are recommended for the duration of the trip as well. Just imagine getting to a hospital for help and having to wait for paperwork because it is in the lake/river with your canoe or back in the busted vehicle . Worst case docs from home can be faxed in minutes. When each leader has a copy - no problem except for collecting the doc at the each of each trip. When an emergency occurs the activity/trip leader needs access to forms normally on paper. Having good documentation is fundamental to success. Having good documentation for awards is also required - it make it a lot easier to plan a program and to keep everyone on target. What is needed is how to organize the data to protect the data, methods to limit access, and how to track access to the data. I plan to use linux, apache, mysql, and php. There are controls at each level - so how to lock down access at each level ? oscar On Friday 07 July 2006 7:21 am, Slide wrote: On 7/6/06, Oscar Schultz [EMAIL PROTECTED] wrote: snip mine first_name middle_name last_name preferred_name gender birth_day birth_month birth_year record_id date_recorded It will all go into a sql table Address, phone, email will be separate tables since people can have multiple of each. My plan is to use either MySQL or PostGRES, php, apache, and linux with a web interface. My list of tables: people, addresses, phones, emails, events, attendance, awards, requirements, images, pictures, completed_awards, completed_requirements, emergency_contacts, medical_forms, and permission_slips should be interesting Be careful with some of this information; are you planning on storing medical information or just a flag saying they have turned in the medical form? Storing medical information would probably be a bad idea. slide ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss
Re: [Ldsoss] Scout Tracking
On 2006.07.07 18:43:37 -0600, Oscar Schultz wrote: True - storing data/forms is challenging. Tracking awards makes planning and program management easier. Access to information however is required for trips. Agreed. The required documentation for an outing to occur is: [... concede listing ...] To prevent document loss normally copies at home are recommended for the duration of the trip as well. Just imagine getting to a hospital for help and having to wait for paperwork because it is in the lake/river with your canoe or back in the busted vehicle . Worst case docs from home can be faxed in minutes. When each leader has a copy - no problem except for collecting the doc at the each of each trip. When an emergency occurs the activity/trip leader needs access to forms normally on paper. Having good documentation is fundamental to success. Ok. I agree that you need access to the paperwork but am failing to see how this means we should input this information into a database. If I track who has what paperwork on file, the filing is a simple thing. Photocopies can (and arguably should) be made anytime someone has a legitemate need. If that means that there are three copies out to leaders, then so be it. Having good documentation for awards is also required - it make it a lot easier to plan a program and to keep everyone on target. I'm not seeing the point here. If I know what each boy has earned, then why do I need to have his email, phone number, dob, etc.? These are easily kept and distributed in another (hopefully, less public) medium. What is needed is how to organize the data to protect the data, methods to limit access, and how to track access to the data. I plan to use linux, apache, mysql, and php. There are controls at each level - so how to lock down access at each level ? I don't see the why we need to handle all of the other information. I'm reluctant to place a leader's convenience over the security of someone's personal information. That's a very slippery slope to embark upon. So that you may better rebut my comments, let me explain that the only use I see for storing the address information is to do mailings. As an LDS leader, I don't have much use for mailings as most of the time quorum presidents do phone calls to get the information to boys not at the weekly meeting. As an LDS leader, I've never needed to wonder about a boy's date of birth. If he's not 18, I don't worry about anything other than working the program. If he's nearing 18, I work with him to get his eagle if that's his interest. Is anyone else doing something else with the DOB? Email may be useful and it would be interesting to see an option to do status mailings. However, I find that there is no substitute for face to face communication with parents when it comes to scouting. I've had *way* too many bad experiences where the parent ends up with half of the information. [...] My list of tables: [...] requirements, images, pictures, completed_awards, completed_requirements, emergency_contacts, medical_forms, and permission_slips I'm curious on the use for the images and pictures tables. The names bring several ideas to mind but I'm wondering what you were after there? Best regards, --Robert pgpNXOHh5QbHi.pgp Description: PGP signature ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss
Re: [Ldsoss] Scout Tracking
Ok. I've put together the initial base classes to meet the criterion from my earlier email (below) about what features should be in the system. However, I haven't defined the paperwork system fully. Most of the classes are obvious, I hope, but just in case they're not, I will be writing up a readme of sorts to go along with these definitions later this week as well as the remainder of the paperwork filing classes. [0] Please take a look and make all of your comments to the list. I promise not to cry if someone says my code sucks. :) If the attachment doesn't go through, let me know and I can mail individually or find somewhere to put it on the net. --Robert [0] I have to be up for work in 5 hours so I'm stopping now. On 2006.06.26 08:57:04 -0700, Robert Nickel wrote: The requirements for the tracking program, in my mind, are quite simple. Reduce the amount of effort required by the Scout Master to track this information and provide meaningful information to the Scout Master or individual scout in a timely manner. Beyond that, other features are just window dressing. The core features that *must* be implemented (Level 1): o Troop roster. - First name, last name, middle initial (optional). - Flag for leader or scout. o Configurable rank requirements. - Since BSA is taking great pleasure in rearranging old requirements and adding in new ones, it's beneficial to have a flexible system for the ranks Scout - Eagle. - These rank requirements should be unique items in case the requirements change and the boy is not responsible for the new requirement structure. o Merit badge listing. - This listing should include the merit badge number, name and whether or not the individual merit badge is a required merit badge. o Troop positions tracking. - Ability to input troop positions and who filled them (if anyone) with start and end dates. o Reporting system. - Answer questions frequently asked by SM and CC like, What boys need for first class? or What paperwork is this boy in need of? or What merit awards have been earned by the troop this year? The features I believe are worth doing (Level 2): o Merit awards for youth and adults. - Duty to God *could* be integrated here but is likely better suited to being a stand alone application if this is to be available for all scouting organizations. - This is a great place to track awards for On My Honor and other similar items. o Attendance roster. - Allow for input of meeting dates and roster of boys attending. o Paperwork tracking system. - Input various items that need to be filled out (i.e. a permission slip for each boy attending a campout). - The system should be flexible enough to accept lists of boys that need to have the paperwork in and a deadline. - Ideally, this could be used for tour permits and other such items. - Some sort of comments field for this system would be ideal allowing for todo items and some minor collaboration between leaders. [...] ScoutTrack.tbz2 Description: Binary data pgpEmLleGFHTk.pgp Description: PGP signature ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss
Re: [Ldsoss] Scout Tracking
Robert Nickel wrote: lol. My efforts were toward the normalization of the database and creation of the php classes for the various objects in a web based system. However, I ... will try to make some sense of what I've been thinking. The core features that *must* be implemented (Level 1): o Troop roster. - First name, last name, middle initial (optional). - Flag for leader or scout. As one who uses their middle name, I am always infuriated when, in this day of TeraByte storage, I encounter computer systems that insist on calling me A, because I use A. Rick Anderson. If you insist on such an archaic limitation, please do NOT add a restriction against the use of a period or space character as legal values in a name. I can't tell you how many computer systems where my first name is A. Rick Anderson :-( But, if you'd send me your initial cut, I would also appreciate having a starting point. -- A. Rick Anderson ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss
re: Re: [Ldsoss] Scout Tracking
As someone who has a hyphen in his last name not from marriage, but from birth it also in infuriating when I come across a computer system that will only accept alpha characters in the last name field. GR Gordon-Ross A. Rick Anderson [EMAIL PROTECTED] wrote: Robert Nickel wrote: lol. My efforts were toward the normalization of the database and creation of the php classes for the various objects in a web based system. However, I ... will try to make some sense of what I've been thinking. The core features that *must* be implemented (Level 1): o Troop roster. - First name, last name, middle initial (optional). - Flag for leader or scout. As one who uses their middle name, I am always infuriated when, in this day of TeraByte storage, I encounter computer systems that insist on calling me A, because I use A. Rick Anderson. If you insist on such an archaic limitation, please do NOT add a restriction against the use of a period or space character as legal values in a name. I can't tell you how many computer systems where my first name is A. Rick Anderson :-( But, if you'd send me your initial cut, I would also appreciate having a starting point. -- A. Rick Anderson ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss -- ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss
Re: [Ldsoss] Scout Tracking
On 2006.06.27 08:33:32 -0400, A. Rick Anderson wrote: [...] As one who uses their middle name, I am always infuriated when, in this day of TeraByte storage, I encounter computer systems that insist on calling me A, because I use A. Rick Anderson. If you insist on such an archaic limitation, please do NOT add a restriction against the use of a period or space character as legal values in a name. I can't tell you how many computer systems where my first name is A. Rick Anderson :-( I need a weekend at least to clean up and remove much of the class definitions to meet the altered items. As to the name limitations, I don't see the problem. If you're controlling the input into the system, you're more than welcome to input Moonbeam if you so choose. Let's try to keep this on-topic and relevant, please. --Robert pgpe9J7ANZEF1.pgp Description: PGP signature ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss
Re: [Ldsoss] Scout Tracking
On 2006.06.26 23:34:24 -0600, Oscar Schultz wrote: Thanks for the feedback. You noted you have outlined the php classes you think are needed - are you willing to post or send me a copy of your classes ? [...] Yes, I'm willing to forward what I have done. However, my original plans were for something just like TroopMaster and were over engineered including personal data for youth and adults and also the DTG requirements. If you're interested, I'll dig them up and send them, but they're not appropriate to what I discussed here. --Robert pgpwI3WgghMU7.pgp Description: PGP signature ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss
Re: [Ldsoss] Scout Tracking
Since you already put in a lot of time and effort you should better know where the problems are in a web based system. Outlining the problems would save anyone just starting a lot of time and false starts. . Please outline what requirements you believe a tracking program should satisfy and what features you believe are needed (perhaps level 1,2 and 3 level requirements/features). Please outline the security/protection requirements (rather than implementation methods) you found. thanks oscar On Sunday 25 June 2006 1:44 am, Robert Nickel wrote: Although this message is not in reply to a specific message, I'm going to reference many of the items spoken by folks. Having put some serious thought and energy into development of a web based troop tracking system, I have been following this thread with a great deal of interest. This has helped me to gel some of the concerns and ideas that I've had in the past together. First; if someone is to sponsor a central database, we should *not* look to the church for a scouting oriented database. We should offer our efforts to BSA. This way, the program could benefit all scouts and not be viewed exclusively as an LDS thing. Second; DTG should become part of MIS, or at the very least, be centralized through the clerks office. This way, all of the features that have been touted of the etrailtoeagle program can be realized via the church email system. Third; to alleviate the concerns that have been expressed about the volume of personal information stored in an online database, I would suggest just not allowing for the storage of that information. What is the requirement for tracking all of the things that TroopMaster tracks? Personally, I think TroopMaster suffers from massive feature creep. Things like insurance values, license numbers and parental contact information should either be tracked completely offline or on paper. Although the improved security garnered by this approach is dubious, the fact that we're trying to track progress and not all the ancillary things associated with scouting should serve as a primary focus. I think that the discussion has been healthy but that there are definitely different views of what the scope of the project is going to be. Without some definition of this scope, the discussion to date can have *very* different meanings for each person on the list. I think that Tom [0] should set down some initial criterion for the project before anyone decides to spin off yet another scout tracking system (YASTS). --Robert [0] It appears that Tom was the originator of the thread from the link that I was given. ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss
RE: [Ldsoss] Scout Tracking
I hope that you still consider setting it up only available to localhost. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dan Hanks Sent: Wednesday, June 14, 2006 5:51 PM To: LDS Open Source Software Subject: Re: [Ldsoss] Scout Tracking On Wed, 14 Jun 2006, Shane Hathaway wrote: Thomas Haws wrote: This is very intriguing. Can you point to an example we might install and try? I hope someone else knows of an example. Conceptually, it's simple, and I can see the solution from start to finish. But I'm surprised it hasn't been done very often. Maybe we need a proof of concept. There's a Perl module called Net::Server (http://search.cpan.org/~rhandom/Net-Server-0.93/lib/Net/Server.pm) that could be used to easily implment a simple HTTP server for use with something like this. Another such module would be HTTP::Daemon (http://search.cpan.org/~gaas/libwww-perl-5.805/lib/HTTP/Daemon.pm). The installer could be smart enough to ask if this is a desktop/standalone install (and use the Perl module or whatever other lightweight httpd is included with the package) or a server install (in which case it would use the Apache or whatever is running on the server. -- Dan ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss
RE: [Ldsoss] Scout Tracking
Installability and easy updates. And easy synchronizing ;) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steven H. McCown Sent: Wednesday, June 14, 2006 10:54 PM To: 'LDS Open Source Software' Subject: RE: [Ldsoss] Scout Tracking Other thoughts: Whatever language is used for this or any general app needs to consider the end user. The general end user is not a power sys admin, but someone who installs out of the box, uses only the defaults, and never updates. If Perl or Ruby or what ever is used is installed on the user's box, then the Scout app needs to keep those up to date on patches and security fixes. To require the user to update Perl or Python is unreasonable and to not keep it up to date is not responsible. Most users are not perpetually WiFi connected, but still use the Internet at home. Most of the church buildings do not have WiFi. That's why a web app would require 2 sets of record keeping -- for most users. I went to church in SLC and most of the male members had PDAs instead of scriptures in books. It's the opposite in most other places that I've been. We're discussing what *we* (computer scientists, sys admins, etc.) would like. What would the average user like? Steve ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss
Re: [Ldsoss] Scout Tracking
Steven McCown explains in detail what was bothering me about using Perl or Ruby. The reality is that those languages and the average Windows box just don't jive. But Java does. Is there a way to do this using Java? Sorry, but as Steven says, we have to consider the end user. And the end user bought his computer at Dell or Walmart with the default version of Windows pre-installed. -- Tom Haws 480-201-5476 OpenOffice.org v. MS Office: Kids love OOo. Wife didn't notice I switched. Get OOo free. There are many causes that I am prepared to die for but no causes that I am prepared to kill for Gandhi ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss
Re: [Ldsoss] Scout Tracking
Steven H. McCown wrote: Most users are not perpetually WiFi connected, but still use the Internet at home. Most of the church buildings do not have WiFi. That's why a web app would require 2 sets of record keeping -- for most users. The web app actually eliminates a set of records... If parents can update their Son's/Daughter's progress on-line then they don't need to track it in their Son's scout handbook or D2G booklet. If the web app is easy to use then parents are more likely to be involved as well; which they should be. As for church buildings being connected I don't see that too far out. For one, the new genealogical software is a web app, from what I understand. Therefore, Family History Centers (usually in stake buildings outside of Utah) will need to be connected. Also, I noticed that our new building, built less than a year ago, has cat-5 ports are in about every room. It seems that someone is planning ahead. I went to church in SLC and most of the male members had PDAs instead of scriptures in books. It's the opposite in most other places that I've been. Many members, both male and female, use PDA's for scriptures (and more) in places like Dallas, TX as well. I imagine the trend is true in about any city or area with the right demographics. We're discussing what *we* (computer scientists, sys admins, etc.) would like. What would the average user like? Don't forget that the parent may be a potential user as well. -stacey. ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss
Re: [Ldsoss] Scout Tracking
Thomas Haws wrote: Steven McCown explains in detail what was bothering me about using Perl or Ruby. The reality is that those languages and the average Windows box just don't jive. That's a big assumption, but I can't deny it, since I don't know Perl or Ruby well enough. Chances are there's someone in each respective community who has made it easy to build Windows installers. But Java does. Is there a way to do this using Java? Sorry, but as Steven says, we have to consider the end user. And the end user bought his computer at Dell or Walmart with the default version of Windows pre-installed. But you don't really want to rely on whatever version of Java the user has installed, do you? That would be a support mess. To keep focused on software development rather than support, you need to ship a particular version of the JRE anyway. I just remembered that Plone has a great example of the kind of installer I've been talking about. You've got to check this out. Go to: http://plone.org/products/plone Just for you, I rebooted into Windows to try out the installer. :-) Roughly, here are all of the steps I went through: 1) The download link on plone.org redirected me to Sourceforge. I chose a download location. 2) My browser popped up the download dialog and I chose to save to the desktop. 3) When the download finished, I double-clicked the .exe file. 4) An installation wizard popped up. I clicked through the license agreement, which was the GPL. 5) I chose where to install it (C:\Program Files\Plone 2). 6) I was prompted for an administrative user name and password. I entered one. 7) After clicking Next / Finish once or twice and waiting a minute, the wizard said it was done and I closed the wizard. 8) I clicked Start | All programs | Plone | Plone (or something like that). 9) A little GUI popped up. I clicked the start button in the GUI, then clicked the view button. 10) A browser window popped up with a page served directly from my laptop, with http://localhost/; in the URL bar. Having accomplished my task, I then rebooted. :-) At no point did the installer look or feel different from other Windows installer. It didn't even tell me it was installing Python and a bunch of libraries, because those are technical details that don't matter to the end user. It's a 15 MB download, but that's because Plone is a big application with lots of bundled support libraries. By comparison, the JRE alone is 18 MB. We could use the Plone installer as an example, since it's fully open source. The GUI for starting and stopping Plone is also written in Python, so we can change it to work with the system tray instead or whatever. Mac support for Python is also quite good from what I hear, but I don't know the details. Shane ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss
Re: [Ldsoss] Scout Tracking
On 6/14/06, Shane Hathaway [EMAIL PROTECTED] wrote: Thomas Haws wrote: This is very intriguing. Can you point to an example we might install and try? I hope someone else knows of an example. Conceptually, it's simple, and I can see the solution from start to finish. But I'm surprised it hasn't been done very often. Maybe we need a proof of concept. I believe the Zesty News application is supposed to work like this, though I haven't tried it myself yet: http://www.blazingthings.com/zestynews/index.html It's written with the Python Turbogears web framework, though I believe you could do the exact same type of thing with Django or Ruby on Rails. Of the three, I prefer Django, even though you didn't ask :-) Bryan ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss
Re: [Ldsoss] Scout Tracking
Thomas Haws wrote: 1. be careful to use cross-platform technologies. Shell scripts, assembly code, and ActiveX are bad ideas, because we need portable code for the next steps. Can you please clarify this? Is PHP a shell script? No, PHP is not a shell script, but I'm not certain it's easily portable to Windows desktops. Does lighttpd run on Windows without Cygwin? (We shouldn't require Cygwin or Apache--they are too heavy for end users.) With Python it's easy to just plop the code in some directory, including libraries, and run it. You can even make a single executable. I imagine other languages provide similar ease of deployment, but I don't know which ones. 2. Server technology I am ashamed to say I have never heard of Django. Isn't PHP nearing lingua franca status with HTML like Javascript? I'm biased against PHP. PHP code rarely separates the presentation layer from the business logic, making unit testing difficult. Unit testing is essential for rapid development. PHP is only one of many web development technologies, and IMHO not the primary one. 3. Development access Can you address the matter of development access? Would we open the project at sourceforge for that first test troop and dish out CVS access liberally? I suppose that's the only way to allow peering at the code? Yes, Sourceforge is the right place. 4. Desktop installation I'm just a lowly Windoze user, but I've never heard of running a web app locally via http://locallhost... I know LAMP apps can be run on Windows, but I've never seen it done by a mere human. For your Uncle, cousin, and Dad, would it be realistic to expect them to install the platform for a web app on their local machine? Yes. The installer will put the web app in the Program Files directory and a shortcut will be added to the menu and desktop. The shortcut will both launch the web app and launch the user's browser once the web app has started. It's not hard to do. An icon in the system tray will indicate the web app is running and give the user the opportunity to stop it. Shane ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss
Re: [Ldsoss] Scout Tracking
On 6/14/06, Shane Hathaway [EMAIL PROTECTED] wrote: Now, as for choosing the web app server technology... yikes. Please be nice to each other. :-) FWIW, I'd vote for Django in this case. Django is written in Python, a highly agile and portable language, and it's inspired by Zope, Ruby on Rails, and other projects. Yay for Django. It rocks. Bryan ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss
Re: [Ldsoss] Scout Tracking
Shane, I'd like to follow up on this: On 6/14/06, Shane Hathaway [EMAIL PROTECTED] wrote: Yes. The installer will put the web app in the Program Files directory and a shortcut will be added to the menu and desktop. The shortcut will both launch the web app and launch the user's browser once the web app has started. It's not hard to do. An icon in the system tray will indicate the web app is running and give the user the opportunity to stop it. So when I open my browser and view source for a given page, I will see form action= what? Expanding my mind here, what are the known species of form action scripts, and which are most amenable to Windows deployment? PHP CGI ASP JSP And last of all, am I even asking the right question? I am assuming we are talking about a web browser application. -- Tom Haws 480-201-5476 OpenOffice.org v. MS Office: Kids love OOo. Wife didn't notice I switched. Get OOo free. There are many causes that I am prepared to die for but no causes that I am prepared to kill for Gandhi ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss
Re: [Ldsoss] Scout Tracking
--- Thomas Haws [EMAIL PROTECTED] wrote: Shane, I'd like to follow up on this: On 6/14/06, Shane Hathaway [EMAIL PROTECTED] wrote: Yes. The installer will put the web app in the Program Files directory and a shortcut will be added to the menu and desktop. The shortcut will both launch the web app and launch the user's browser once the web app has started. It's not hard to do. An icon in the system tray will indicate the web app is running and give the user the opportunity to stop it. That means, though, that you require the user to have a web server installed on his computer (either because your installer put it there, or because he already had one). This brings me back to a comment I made several days ago: sure, I *can* install a LAMP application on my Powerbook, but I don't think it's reasonable to require every user of the system to do so. So when I open my browser and view source for a given page, I will see form action= what? Expanding my mind here, what are the known species of form action scripts, and which are most amenable to Windows deployment? PHP CGI ASP JSP In general, there are: - Web server modules (mod_perl, mod_php, ASP, ISAPI plugins and the like) - naturally very dependent on a specific HTTP server - CGI scripts (can be written in a wide variety of languages, Perl and PHP being common, but Python, Ruby, C, Delphi and many others are also used) - generally portable to multiple HTTP servers, so long as the language will run on your platform of choice. Don't try to do Delphi-based CGI on Unix. - Programs that include their own custom HTTP servers - and whatever Java uses. Java is weird that way :) ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss
Re: [Ldsoss] Scout Tracking
Gary Thornock wrote: That means, though, that you require the user to have a web server installed on his computer (either because your installer put it there, or because he already had one). This brings me back to a comment I made several days ago: sure, I *can* install a LAMP application on my Powerbook, but I don't think it's reasonable to require every user of the system to do so. I don't think so either, and that's why I'm not suggesting LAMP. I'm suggesting what you said later: - Programs that include their own custom HTTP servers We don't even have to build the HTTP server, since dozens of Free custom HTTP servers already exist. All the program has to do is open a listening port and respond to HTTP requests. HTTP servers can be really, really simple when you don't care about advanced HTTP capabilities. Shane ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss
Re: [Ldsoss] Scout Tracking
This is very intriguing. Can you point to an example we might install and try? If I understand right, you are saying I can run it on my desktop for my troop, or I can run it at a web server for my troop or for the entire council or church? -- Tom Haws 480-201-5476 OpenOffice.org v. MS Office: Kids love OOo. Wife didn't notice I switched. Get OOo free. There are many causes that I am prepared to die for but no causes that I am prepared to kill for Gandhi ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss
Re: [Ldsoss] Scout Tracking
On Wed, 14 Jun 2006, Shane Hathaway wrote: Thomas Haws wrote: This is very intriguing. Can you point to an example we might install and try? I hope someone else knows of an example. Conceptually, it's simple, and I can see the solution from start to finish. But I'm surprised it hasn't been done very often. Maybe we need a proof of concept. There's a Perl module called Net::Server (http://search.cpan.org/~rhandom/Net-Server-0.93/lib/Net/Server.pm) that could be used to easily implment a simple HTTP server for use with something like this. Another such module would be HTTP::Daemon (http://search.cpan.org/~gaas/libwww-perl-5.805/lib/HTTP/Daemon.pm). The installer could be smart enough to ask if this is a desktop/standalone install (and use the Perl module or whatever other lightweight httpd is included with the package) or a server install (in which case it would use the Apache or whatever is running on the server. -- Dan ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss
RE: [Ldsoss] Scout Tracking
Other thoughts: Whatever language is used for this or any general app needs to consider the end user. The general end user is not a power sys admin, but someone who installs out of the box, uses only the defaults, and never updates. If Perl or Ruby or what ever is used is installed on the user's box, then the Scout app needs to keep those up to date on patches and security fixes. To require the user to update Perl or Python is unreasonable and to not keep it up to date is not responsible. Most users are not perpetually WiFi connected, but still use the Internet at home. Most of the church buildings do not have WiFi. That's why a web app would require 2 sets of record keeping -- for most users. I went to church in SLC and most of the male members had PDAs instead of scriptures in books. It's the opposite in most other places that I've been. We're discussing what *we* (computer scientists, sys admins, etc.) would like. What would the average user like? Steve ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss
RE: [Ldsoss] Scout Tracking
On Tue, 13 Jun 2006, Steven H. McCown wrote: The other issue is what value would a centralized database really offer? For day-to-day usage, it would offer zero value. If a scout moved wards, it would allow his records to be transferred. However, much of that is maintained by BSA, anyway. If local databases were used, then 'transferrable data objects' could be used to transfer information between databases from the old ward to the new. I have to respectfully disagree. I think the value of a centralized database is much greater than zero. A centralized database would allow parents to enter updated data about what their kids have done. The leaders would be able to see this and add their ok to that. Scout leaders can enter information about what requirements are passed off at weekly meetings and the parents can be on the same page. Bishops can see in one spot the progress of each of the youth over which he has stewardship. The key benefit I see from all this is a central data store making it possible for everyone involved, parents, leaders, and youth, to be on the same page in a much more efficient fashion. Yes there will be some who may choose to 'opt-out', but I think that will be a small minority. I understand there are risks and dangers involved here. But I would contend that there is risk in much of what we do in life. We can't let that paralyze us from moving forward, however. I respectfully disagree with you in that I believe the rewards from a centralized data store are very great, and worth the potential risk involved (which I believe can be mitigated sufficiently with some careful thought and attention). To bring this home, I have 4 children, all minors, so I understand the issues from a parent's point of view. I'm very aware of the risks of putting information on the Internet, and very cautious as to what I let my kids do on the Internet. That said, however, I'm confident that the church can design a system (hopefully with the communitiy's input and help) that will allow this tracking to occur and in a fashion that I would feel comfortable in having information about my own children to be stored in it. I don't see building a web app as just something to do because it's 'cool', but more as something that will provide a very large benefit. The biggest problem with any tracking process is that the Scoutmasters are usually quite lax about record keeping, in the first place. If one or That's a pretty broad generalization that I don't think is valid. There are scoutmasters that are very good at record-keeping. Perhaps the reason many are 'lax' is because they have to deal with all the paper and pencil ;-). A centralized system would alleviate much of that, I think. At any rate, to sum up: I recognize there are risks involved, and I understand those risks, but I believe they can be addressed sufficiently such that the potential rewards will outweigh those risks. FWIW, -- Dan :-) ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss
Re: [Ldsoss] Scout Tracking
Steven H. McCown wrote: The reason that I proposed the non-centralized storage option is that not that security is more or less, but because attacks on very small databases yield very small rewards. In contrast, attacks on highly-centralized databases offer greater rewards for the attacker. The architecture I suggested would effectively turn the centralized server into warehouse of small, practically unbreakable databases. A desktop application will be the only way to use the database. The database will be encrypted with high grade encryption and using a long key. When users enter their password, they will enter the password for accessing the key, not for opening the database. The key will be stored on the user's hard drive (or even in the TPM module embedded in their computer), not on the web server. To allow a new user to access the database, that user needs, at a minimum, both the key to the database (an RSA key, perhaps) and the password for using that key. Users will be required to copy keys between computers using removable media. Even administrators of the web server won't be able to access the databases because they won't have the keys. It wouldn't even matter if they guessed passwords. A password of 123 is OK as long as the key is guarded. If everyone loses their keys, the database will become impossible to access. There is no master key. The only practical way to break such a system is to steal private keys one at a time or find a flaw in the way the software is using cryptography. Conceivably, someone could write a virus that steals private keys, but *any* desktop application is vulnerable to that attack, so that's merely an argument for not using operating systems that have a lot of vulnerabilities. So the only concern is that the application has to use cryptography correctly. Now that we have OpenSSL, that's not very hard. Shane ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss
Re: [Ldsoss] Scout Tracking
All of your suggestions could also be implemented in centralized database, if desired. But the key management seems potentially unwieldy if you want every parent and every scout to be able to access the database. Charles -Original Message- From: Shane Hathaway [EMAIL PROTECTED] Subject: Re: [Ldsoss] Scout Tracking Date: Tue, 13 Jun 2006 10:32:44 -0600 To: [EMAIL PROTECTED], LDS Open Source Software ldsoss@lists.ldsoss.org Reply-To: LDS Open Source Software ldsoss@lists.ldsoss.org Steven H. McCown wrote: The reason that I proposed the non-centralized storage option is that not that security is more or less, but because attacks on very small databases yield very small rewards. In contrast, attacks on highly-centralized databases offer greater rewards for the attacker. The architecture I suggested would effectively turn the centralized server into warehouse of small, practically unbreakable databases. A desktop application will be the only way to use the database. The database will be encrypted with high grade encryption and using a long key. When users enter their password, they will enter the password for accessing the key, not for opening the database. The key will be stored on the user's hard drive (or even in the TPM module embedded in their computer), not on the web server. To allow a new user to access the database, that user needs, at a minimum, both the key to the database (an RSA key, perhaps) and the password for using that key. Users will be required to copy keys between computers using removable media. Even administrators of the web server won't be able to access the databases because they won't have the keys. It wouldn't even matter if they guessed passwords. A password of 123 is OK as long as the key is guarded. If everyone loses their keys, the database will become impossible to access. There is no master key. The only practical way to break such a system is to steal private keys one at a time or find a flaw in the way the software is using cryptography. Conceivably, someone could write a virus that steals private keys, but *any* desktop application is vulnerable to that attack, so that's merely an argument for not using operating systems that have a lot of vulnerabilities. So the only concern is that the application has to use cryptography correctly. Now that we have OpenSSL, that's not very hard. Shane ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss -- Shaving brushes You'll soon see 'em On the shelf In some Museum Burma-Shave http://burma-shave.org/jingles/1943/shaving_brushes ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss
Re: [Ldsoss] Scout Tracking
Charles Fry wrote: All of your suggestions could also be implemented in centralized database, if desired. Is that different from what I suggested? But the key management seems potentially unwieldy if you want every parent and every scout to be able to access the database. I think that's a small price to pay for a central database without the associated privacy risk. The key only has to be copied once per computer. The desktop application could even provide a menu option or dialog for exporting and importing keys. It's true that keys should not be sent by email, but we're talking about groups who meet in person often anyway. Shane ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss
Re: [Ldsoss] Scout Tracking
On Tue, Jun 13, 2006 at 10:32:44AM -0600, Shane Hathaway wrote: The architecture I suggested would effectively turn the centralized server into warehouse of small, practically unbreakable databases. I don't see the need for a centralized churchwide database. This whole discussion is in the end just academic as someone already mentioned that none of this would be necessary if parents took enough interest in their son's scout participation, which is the ideal. Why should any of this be bigger than troop level? If there's any bureaucracy above the scoutmaster I doubt they are going to be paying attention to the scouts on an individual level, therefore why do they need that kind of information. I agree with Steven here. The merits of a centralized database seem as though they are just the convenience of data miners and, potentially, of identity thiefs, unless someone can convince me of some great compelling benefit of centralization. Justin ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss
Re: [Ldsoss] Scout Tracking
Justin R Findlay wrote: On Tue, Jun 13, 2006 at 11:10:50AM -0600, Shane Hathaway wrote: We don't need a churchwide database, we only need a place for people to put their databases so that others in the troop can access the database even when the scoutmaster's computer is turned off. So, like the ward and stake web sites? Yes, that would be fine if that's what the Church wants to do, but this software ought to also work for troops that are not associated with wards and stakes. Shane ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss
Re: [Ldsoss] Scout Tracking
Justin R Findlay wrote: I agree with Steven here. The merits of a centralized database seem as though they are just the convenience of data miners and, potentially, of identity thiefs, unless someone can convince me of some great compelling benefit of centralization. I would also agree with Steven about the concept of a large, centralized database for other reasons as well. If you get outside of Utah you will find that most boy scouts are not LDS (In fact, only about 25% boy scouts are LDS from what I have heard).Here in Texas, we see troops that are associated with many other churches or groups. Some of these other groups may only have one troop which really doesn't merit the expense and overhead of a large database server. In fact, I would like see a scout/D2G tracking web app use something like SQLite or Berkeley DB rather than something with a lot of overhead like even mySQL or Postgress. -stacey. ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss
Re: [Ldsoss] Scout Tracking
Stacey wrote: Justin R Findlay wrote: I agree with Steven here. The merits of a centralized database seem as though they are just the convenience of data miners and, potentially, of identity thiefs, unless someone can convince me of some great compelling benefit of centralization. I would also agree with Steven about the concept of a large, centralized database for other reasons as well. If you get outside of Utah you will find that most boy scouts are not LDS (In fact, only about 25% boy scouts are LDS from what I have heard).Here in Texas, we see troops that are associated with many other churches or groups. Some of these other groups may only have one troop which really doesn't merit the expense and overhead of a large database server. In fact, I would like see a scout/D2G tracking web app use something like SQLite or Berkeley DB rather than something with a lot of overhead like even mySQL or Postgress. I also agree that a centralized database for many troops is risky. What I want to see is a separate database for each troop, stored on the troop's server of choice, in an encrypted form, with decryption only possible through two-factor authentication (a long digital key and a password). Shane ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss
Re: [Ldsoss] Scout Tracking
Slide wrote: I liked the idea someone mentioned about having a sort of source control mentality about it all. You can grab a working copy and put it on your laptop for meetings and then when you are done, you can commit the changes back into the main repository or database. This could be achieved in a variety of ways. That's a fine idea, but an important risk is the difficulty of merging conflicting updates. Conflict resolution in source code works because it's all text and you can use the same tool (a text editor) to resolve conflicts as you use to write code. Conflict resolution in a database can be much trickier. The problems can be solved, but in practice, the need to avoid and resolve conflicts tends to influence the design of the whole application. Shane ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss
Re: [Ldsoss] Scout Tracking
Thomas Haws wrote: You are right that Scouting advancement records are a local concern. The main Scouting record-keeping problems are: -Boy loses Scout book -Scoutmaster or Committee changes or leaves area -Scout shows up in area without records These aren't academic. And centralized storage addresses all three. Nobody above the troop level is interested in the records, but centralized storage relieves a burden from the family and the Troop Committee. A troop-specific central database also solves the first two problems. The third problem could be solved using a secure records transfer process involving a centralized database that only facilitates the transfer but does not actually have the ability to decrypt the records in transit. Shane ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss
RE: [Ldsoss] Scout Tracking
My attitude is not that it can't be done, but that it shouldn't be done. Until the online database is 'hack proof', then I will choose to abstain. Since 'hack proof' is unattainable. Steve -Original Message- From: Bryan Murdock [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 07, 2006 8:19 AM To: [EMAIL PROTECTED]; LDS Open Source Software Subject: Re: [Ldsoss] Scout Tracking I think your concerns are vitally important to keep in mind, but the attitude of it can't be done is not one that will get us anywhere. ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss
RE: [Ldsoss] Scout Tracking
THanks for your feedback Steven. I do understand where you are coming from although I do not entirely agree. One thing we both can agree to however is that security has to be a top concern and should not be treated lightly. Tom Steven H. McCown [EMAIL PROTECTED] 06/09/06 6:25 pm Tom I hear all the time about how such and such a website got hacked and the information leaked.Im prior military so Ive been following the VA incident -- and that wasnt even web hosted.The reality is that hackers or their bots zombies etc. attempt intrusions on all websites every day. Given that most websites will be hacked at one time or other.I have statistics but Ill forgo them for now. Given that most websites will be hacked the real question is what we choose to put there.It wouldnt bother me too much if someone found out that I was a church member my address that I served a mission or whos in my family.Those things are all a matter public record anyway.It wouldnt bother me if someone found out how much tithing that I paid either.If someone found out my credit card number then Visa would cover my losses and issue me a new card number.So thats not a permanent problem. However YM / YW / Scouting records paint a much more personal account of the individual.They have things such as likes dislikes achievements associations other personal information etc.If those things coupled with name and address fell into the wrong hands then bad things could happen.Here is a sample article about kids and myspace.com http://www.msnbc.msn.com/id/7668788/. In the case of myspace.com kids are voluntarily disclosing information that sets them up for stalking and the like.This has gotten so bad that public schools are starting to try to ban students participation or to monitor them for inappropriate activity.I dont want to open a discussion as to whether that is good or bad but the schools are at least trying to protect the children. If the church were to sponsor what would really amount to an online database of personally identifiable personal information of minor children then they would be making themselves hugely liable if that information ever got out. Groups like the ACLU would have a heyday.The VA had to announce recently that2M soldiers information was compromised.Imaging the PR and financial liability if the church had to make the same announcement.This possibility has to be weighed against the benefit of an online system vs. keeping those records by hand or in another non-centralized manner. I took a class at BYU that discussed things like risk management and mitigating risk.Most of us glossed over that course in favor of building cool stuff.As technologists scientists and engineers we all have to pay more attention to the ramifications of technology than we do about the technology itself. So to answer your question if the church hosted a minor child information tracking website then no I would still not be comfortable with that.I would opt out and my opting out would unfortunately hinder the utility of the overall system. Steve -Original Message- From: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] On Behalf Of Tom Welch Sent: Wednesday June 07 2006 7:29 AM To: LDS Open Source Software Subject: Re: Ldsoss Scout Tracking If the Church were to host the site would that alleviate your concernsCurrently you can get a ward listing of all members in the ward their address and phone numbers from the ward unit website.This would not be much different. Tom Steven H. McCown wrote: I can appreciate all the fervor for a web-based app.However 1 The church has said no websites.You cant get away with making the this is scouting and that is the church distinction anymore. 2 It is a legal problem to start posting information about minor children to the Internet.That would have to be decided at Church HQ and not by the local units.They dont even allow information to be posted into Family Search about living people
RE: [Ldsoss] Scout Tracking
I can appreciate all the fervor for a web-based app. However, 1) The church has said no websites. You can't get away with making the this is scouting and that is the church distinction, anymore. 2) It is a legal problem to start posting information about minor children to the Internet. That would have to be decided at Church HQ and not by the local units. They don't even allow information to be posted into Family Search about living people, they just insert a LIVING placeholder. Being involved with security professionally, I would not give my consent. This is a huge pitfall -- despite good intentions -- it would be wise not to fall into it. Steve -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dan Hanks Sent: Tuesday, June 06, 2006 9:04 AM To: LDS Open Source Software Subject: Re: [Ldsoss] Scout Tracking On Tue, 6 Jun 2006, Tom Welch wrote: Web-based would be great, but with the church's policy on non-official websites, where does that put the local unit that would want to install and use such a web-based app? -- Dan ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss
RE: [Ldsoss] Scout Tracking
However, the offline portion of MIS is offline. The online portion is fairly well secure. I don't trust my local scoutmaster or (sorry) the OSS community to make that assertion. PHP is about as secure as IE on a bad day... The distinction here is that MIS does not have personal information about likes, hobbies, awards, projects, etc. An online scouting tracking program would have more similarities with myspace.com than with the MIS. That's a huge distinction. In order to begin to think about an online database/app, you would be required to allow parents to opt out. As soon as one parent opted out, the online database would be more work for the Scoutmaster than it would be worth and they'd stop using it. Steve -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Manfred Riem Sent: Tuesday, June 06, 2006 10:42 AM To: 'LDS Open Source Software' Subject: RE: [Ldsoss] Scout Tracking Hi Gary, Actually I think without wanting to start a legal debate about it this would be covered by you as a parent allowing your kids to be entered in the MIS already. Manfred. ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss
Re: [Ldsoss] Scout Tracking
Web based is definitely the way to go. I have been mulling over doing something like this for some time. I'd be willing to help as time permits. --Richard On 6 Jun 2006 at 8:42, Tom Welch wrote: Slide wrote: What would be great is if you could also have a plug-in type system for working with the various religious awards as well (Duty to God for LDS) which would then allow other Scouting groups to take advantage of it without tying it to just LDS Scouting. Yes, DTG is on the map to integrate into this program. The thoughts were to create some kind of a web based application so that parents, scout leaders and boys can all work together. -- Tom Welch [EMAIL PROTECTED] (801) 240-1609 (858) 829-4614 - Cell - - NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. - - ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss
re: RE: [Ldsoss] Scout Tracking
I would agree with both your concerns Steven, accept that, after reading the entire email trail from yesterday, this appears to be a project initiated by Church HQ and not some random person on the listserve. The church has said no unofficial websites - this to me would be an official website. GR Steven H. McCown [EMAIL PROTECTED] wrote: I can appreciate all the fervor for a web-based app. However, 1) The church has said no websites. You can't get away with making the this is scouting and that is the church distinction, anymore. 2) It is a legal problem to start posting information about minor children to the Internet. That would have to be decided at Church HQ and not by the local units. They don't even allow information to be posted into Family Search about living people, they just insert a LIVING placeholder. Being involved with security professionally, I would not give my consent. This is a huge pitfall -- despite good intentions -- it would be wise not to fall into it. Steve -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dan Hanks Sent: Tuesday, June 06, 2006 9:04 AM To: LDS Open Source Software Subject: Re: [Ldsoss] Scout Tracking On Tue, 6 Jun 2006, Tom Welch wrote: Web-based would be great, but with the church's policy on non-official websites, where does that put the local unit that would want to install and use such a web-based app? -- Dan ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss -- ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss
RE: [Ldsoss] Scout Tracking
A scout program would be a great idea. Basing it using a web interface is also a great idea. Hopefully the program would also be setup to track the awards the adults need to be working on , their training, etc. As I understand the Church's position it is there are to be no web sites other than lds.org representing the Church. This does not mean using http://127.0.0.1/scout_tracking_tool is forbidden. The ability to connect remotely is not limited to web based applications - the windows desktop, X, KDE ,gnome, MacOSX, etc can all be connected to remotely - if the network and machine are configured to permit it. Web based applications - when written and carefully managed are neither less nor more secure than desktop programs. The web interface is simply a different api set than the various desktops that are available. There are many desktop programs which when carefully examined are not secure. The security requirement must be written with security as part of the program foundation rather than as some assumption based on other elements providing the security. I would love to see a web based open source scout/YM/YW application program. If the day ever comes where remote connections to Church applications are permitted it will be a great day. Doing a http://www.lds.org/myward/mls/ymyw_tracking would be excellent. In the interm being able to do a http://127.0.0.1/mls/ymyw_tracking would be excellent compared to the resources available today. Another way could be to ssh to a site , then run a X based browser such as konqueror or mozilla and then http://lds.org/mls/ymyw_tracking. The site could be ssh -X [EMAIL PROTECTED] . The requirements to keep all mls/youth/??? data off the internet would be meet due to ssh. The myaccount would be manageable - simply check your recommend - there are 2 numbers which could be used to control access for each member. Releasing the program as open source would not cause a security breach since access to the program nor the data the program would use would not be available without the required ssh account. The program would still be web based as access to anyone wishing to use it stand alone - such as the jayees sponsoring the scout troop I was a member of many years ago. They would simply setup a private LOCAL server and access it as http://127.0.0.1/scout/_tracking_tool . THe data 127.0.0.1 remains behind the firewall no data should leak and the only data in the program is what is entered locally. have a great day oscar The point is to strengthen the testimony of those involved in the various programs. -- Original message -- From: Steven H. McCown [EMAIL PROTECTED] I can appreciate all the fervor for a web-based app. However, 1) The church has said no websites. You can't get away with making the this is scouting and that is the church distinction, anymore. 2) It is a legal problem to start posting information about minor children to the Internet. That would have to be decided at Church HQ and not by the local units. They don't even allow information to be posted into Family Search about living people, they just insert a LIVING placeholder. Being involved with security professionally, I would not give my consent. This is a huge pitfall -- despite good intentions -- it would be wise not to fall into it. Steve -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dan Hanks Sent: Tuesday, June 06, 2006 9:04 AM To: LDS Open Source Software Subject: Re: [Ldsoss] Scout Tracking On Tue, 6 Jun 2006, Tom Welch wrote: Web-based would be great, but with the church's policy on non-official websites, where does that put the local unit that would want to install and use such a web-based app? -- Dan ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss
RE: [Ldsoss] Scout Tracking
Hi Tom, You can only get that list if all the members agree to have it on there. Each member can elect to be removed from the listing. Manfred Riem [EMAIL PROTECTED] http://www.manorrock.org/ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tom Welch Sent: Wednesday, June 07, 2006 7:29 AM To: LDS Open Source Software Subject: Re: [Ldsoss] Scout Tracking If the Church were to host the site, would that alleviate your concerns? Currently you can get a ward listing of all members in the ward, their address and phone numbers from the ward unit website. This would not be much different. Tom Steven H. McCown wrote: I can appreciate all the fervor for a web-based app. However, 1) The church has said no websites. You can't get away with making the this is scouting and that is the church distinction, anymore. 2) It is a legal problem to start posting information about minor children to the Internet. That would have to be decided at Church HQ and not by the local units. They don't even allow information to be posted into Family Search about living people, they just insert a LIVING placeholder. Being involved with security professionally, I would not give my consent. This is a huge pitfall -- despite good intentions -- it would be wise not to fall into it. Steve -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dan Hanks Sent: Tuesday, June 06, 2006 9:04 AM To: LDS Open Source Software Subject: Re: [Ldsoss] Scout Tracking On Tue, 6 Jun 2006, Tom Welch wrote: Web-based would be great, but with the church's policy on non-official websites, where does that put the local unit that would want to install and use such a web-based app? -- Dan ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss -- Tom Welch [EMAIL PROTECTED] (801) 240-1609 (858) 829-4614 - Cell -- NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. -- ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss
Re: [Ldsoss] Scout Tracking
OK, so that would have to be a requirement of this software as well. Opt-out of being listed. I'm just throwing out ideas. There is nothing to say that we can't develop an application that can be both web based and stand alone. We are in the brainstorming mode here. To Manfred Riem wrote: Hi Tom, You can only get that list if all the members agree to have it on there. Each member can elect to be removed from the listing. Manfred Riem [EMAIL PROTECTED] http://www.manorrock.org/ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Tom Welch Sent: Wednesday, June 07, 2006 7:29 AM To: LDS Open Source Software Subject: Re: [Ldsoss] Scout Tracking If the Church were to host the site, would that alleviate your concerns? Currently you can get a ward listing of all members in the ward, their address and phone numbers from the ward unit website. This would not be much different. Tom Steven H. McCown wrote: I can appreciate all the fervor for a web-based app. However, 1) The church has said no websites. You can't get away with making the "this is scouting and that is the church" distinction, anymore. 2) It is a legal problem to start posting information about minor children to the Internet. That would have to be decided at Church HQ and not by the local units. They don't even allow information to be posted into Family Search about living people, they just insert a "LIVING" placeholder. Being involved with security professionally, I would not give my consent. This is a huge pitfall -- despite good intentions -- it would be wise not to fall into it. Steve -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Dan Hanks Sent: Tuesday, June 06, 2006 9:04 AM To: LDS Open Source Software Subject: Re: [Ldsoss] Scout Tracking On Tue, 6 Jun 2006, Tom Welch wrote: Web-based would be great, but with the church's policy on non-official websites, where does that put the local unit that would want to install and use such a web-based app? -- Dan ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss -- Tom Welch [EMAIL PROTECTED] (801) 240-1609 (858) 829-4614 - Cell -- NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. -- ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss -- Tom Welch [EMAIL PROTECTED] (801) 240-1609 (858) 829-4614 - Cell --
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 Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss
RE: [Ldsoss] Scout Tracking
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. 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. BTW Linus didn't create Redhat it is just one instance of a Linux distro. Kind regards, Manfred Riem [EMAIL PROTECTED] http://www.manorrock.org/ -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 Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss
Re: [Ldsoss] Scout Tracking
Steven H. McCown wrote: 2) It is a legal problem to start posting information about minor children to the Internet. That would have to be decided at Church HQ and not by the local units. They don't even allow information to be posted into Family Search about living people, they just insert a LIVING placeholder. Being involved with security professionally, I would not give my consent. This is a huge pitfall -- despite good intentions -- it would be wise not to fall into it. As a father of seven and the former owner of an internet security company I don't view this as an huge problem: (1) I currently use etrailtoeagle.com to track the D2G progress of our YM. However, I don't use the YM's full name but just their first names or nickname. e.g. Johnny, Billy, Joey. There is no reason to use the full name. (2) About the only personal information you would be posting to a website is the child's birthday. Something that is public record anyway. (3) I am more worried about other websites with my children's information. For example: In Texas, most of the public schools have a lot more information about our children on their websites. I log in to the school web site to see my children's grades and attendance records. In addition, the school website has my child's address, parent's names, etc. (4) For the ultra security minded parents you simply allow them to opt out and track their own kid's progress them self. Of course, this is something that every YM's leaders would hope for. That is, the parent, who is ultimately responsible, be fully involved in their child's life. If this were the case for all our YM and their parents then we wouldn't have a need for tracking software or this discussion. Regards, -stacey. ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss
Re: [Ldsoss] Scout Tracking - getting back on the trail
I've been reading this thread with some interest to see where it's going. Right now, it appears that the discussion is being dragged down a series of familiar self-inflicted rat holes. What would be most helpful to getting something productive, Tom, and others from HQ, is to offer, at a minimum, a rough design spec and/or set of sys req, to set the stage. If this is purely a conceptual exercise, then someone from HQ needs to lead the discussion, starting with a set of business requirements, and fleshing things out from there - AND not letting the discussion tail off into the weeds. Many of the people on this list are programmers first, designers second, if at all. They can give you elegant and clever solutions, but those solutions have no meaning without a framework to hang them on. Otherwise you will get the wounded duck, spiraling into the pond exercise from what was a good starting point. ...Paul Bryan Murdock wrote: On 6/7/06, Tom Welch [EMAIL PROTECTED] wrote: OK, so that would have to be a requirement of this software as well. Opt-out of being listed. Opt-out of having what listed for whom? We are still a long way off of even answering those questions. Others have given great responses to these premature security concerns, so I'll just say, amen, to them and leave it at that. Bryan ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss
Re: [Ldsoss] Scout Tracking - getting back on the trail
Before we get to use-cases, lets start at the bottom: 1. Define the problem: ie: There is a need to track scouts and their information 2. From that, branch out into more detail with regard to business process. ie: I need to track scouts with in my district, Of the scouts in my district, the following information about their activities/awards/rank are important... 3. These constitute constraints and rules surrounding how you are handling the problem in a manual fashion. 4. Identify the data elements (not int, char, unsigned, but name, rank, troop, etc.) that are needed and necessary to address the problem and apply the rules. Now you can build specific use cases around the business processes you've identified, and from there dive into as much detail pain as you are willing to handle. The key is simplicity...Many simple rules and cases are much easier to map out and automate, than small sets of convoluted and incomplete rules and sets. Once you can walk someone end to end through the process of tracking the scouts, and there are no holes in either procedures or data elements, then we start with the technical design and framework, plus the user interface - no prototype yet... That comes after design proof.. In the meantime, someone from HQ should take the lead and manage the output from the group into a cohesive set of documentation from which the design will be derived. I never start coding anything until I know exactly what I need to do - no surprises that way, and no Microsoft bend it to fit, paint it match development. A. Rick Anderson wrote: Paul Penrod wrote: If this is purely a conceptual exercise, then someone from HQ needs to lead the discussion, starting with a set of business requirements, and fleshing things out from there - AND not letting the discussion tail off into the weeds. Many of the people on this list are programmers first, designers second, if at all. They can give you elegant and clever solutions, but those solutions have no meaning without a framework to hang them on. Otherwise you will get the wounded duck, spiraling into the pond exercise from what was a good starting point. As one who has been shooting at the duck grin, this is an excellent point! Would it make sense for this group to write up some use-cases/scenarios or simple stories as a means of driving out the requirements? That way, people could define the feature or issue that is of a concern to them in a use-case or story. ex: write-up a use-case for a parent who choses to opt-out, or a story of a data-voyeur trying to access someone else's information (whatever that may be), or of a district leader trying to validate the merit badges for an Eagle Scout candidate. All those who want to contribute could write up the stories, the actual folks who want to code the solution decide which ones they care about and want to do first and you have the beginnings of a set of functional requirements. Non-functional requirements can be driven out the same way, but most programmers don't want to think of those :-) ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss
Re: [Ldsoss] Scout Tracking - getting back on the trail
We're in violent agreement! I do several iterations on a Use-Case, adding detail and information as I drill down. What you are calling a Business Process, I'd capture on the second iteration of use-cases as a business level use-case. See Writing Effective Use Cases by Alistar Cockburn. He recommends 5 abstraction levels for use-cases. The steps of a high level use-case become full-blown use-cases themselves, but at a lower level of abstraction. The alternative paths through a use-case constitute use-case scenarios. In a simple domain like this, I'd keep the business rules in the use-case just to reduce the number of documents to manage. Then, you define wire-frames or page mockup to capture the essence of the user-interaction. Based on the business-level use-cases you create a Screen-Flow showing the navigation path between the diagrams. Now you instantiate the use-case scenarios with specific data values and you end up with test-cases that you can validate before you even touch design. Make sure that you have a test-case that validates every business rule. The combination of these test-cases constitute an acceptance test. Before you even consider technology, you have defined the success criteria and there are no surprises to either the customer or the developer. Paul Penrod wrote: Before we get to use-cases, lets start at the bottom: 1. Define the problem: ie: There is a need to track scouts and their information 2. From that, branch out into more detail with regard to business process. ie: I need to track scouts with in my district, Of the scouts in my district, the following information about their activities/awards/rank are important... 3. These constitute constraints and rules surrounding how you are handling the problem in a manual fashion. 4. Identify the data elements (not int, char, unsigned, but name, rank, troop, etc.) that are needed and necessary to address the problem and apply the rules. Now you can build specific use cases around the business processes you've identified, and from there dive into as much detail pain as you are willing to handle. The key is simplicity...Many simple rules and cases are much easier to map out and automate, than small sets of convoluted and incomplete rules and sets. Once you can walk someone end to end through the process of tracking the scouts, and there are no holes in either procedures or data elements, then we start with the technical design and framework, plus the user interface - no prototype yet... That comes after design proof.. In the meantime, someone from HQ should take the lead and manage the output from the group into a cohesive set of documentation from which the design will be derived. I never start coding anything until I know exactly what I need to do - no surprises that way, and no Microsoft bend it to fit, paint it match development. A. Rick Anderson wrote: Paul Penrod wrote: If this is purely a conceptual exercise, then someone from HQ needs to lead the discussion, starting with a set of business requirements, and fleshing things out from there - AND not letting the discussion tail off into the weeds. Many of the people on this list are programmers first, designers second, if at all. They can give you elegant and clever solutions, but those solutions have no meaning without a framework to hang them on. Otherwise you will get the wounded duck, spiraling into the pond exercise from what was a good starting point. As one who has been shooting at the duck grin, this is an excellent point! Would it make sense for this group to write up some use-cases/scenarios or simple stories as a means of driving out the requirements? That way, people could define the feature or issue that is of a concern to them in a use-case or story. ex: write-up a use-case for a parent who choses to opt-out, or a story of a data-voyeur trying to access someone else's information (whatever that may be), or of a district leader trying to validate the merit badges for an Eagle Scout candidate. All those who want to contribute could write up the stories, the actual folks who want to code the solution decide which ones they care about and want to do first and you have the beginnings of a set of functional requirements. Non-functional requirements can be driven out the same way, but most programmers don't want to think of those :-) ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss -- A. Rick Anderson ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss
Re: [Ldsoss] Scout Tracking
On Wed, Jun 07, 2006 at 02:12:08PM -0400, A. Rick Anderson wrote: 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. Reminds me of the invention of calculus independently by Newton and Leibnitz. If either (regardless that both Newton and Leibnitz stand out among the world's recognized most intelligent people) were required to begin with Weirstrauss', and Riemann's, etc. formal statutes and methods of proof that we have today calculus would never have been invented. Justin ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss
Re: [Ldsoss] Scout Tracking
On Tue, Jun 06, 2006 at 07:34:23AM -0600, Tom Welch wrote: I used TroopMaster in the past and it did not require me to purchase a new license each year. However that was about 3 years ago and they may have changed their pricing plan. The biggest problem that I had with TroopMaster was that it is not easy to share with the next scout master that comes into the calling. At the Church we are looking at sponsoring an open source project around scouting. Any interested people that would like to work on such a program? I'm admittedly not very well informed about the requirements of the boy scouts program, but I'm curious about this: if the church sponsored an open-source project around scouting, would it be possible to set it up in such a way that it could be easily adjusted to: A) Duty to God (which i also know very little about) B) Young Women's Personal Progress the personal progress program involves fulfilling a number of goals in a variety of categories, and then some larger goals at the end... It seems that if this is going to be an official Church-sanctioned project, it would be ideal to make it expandable to tracking those tasks as well... ~Erin -- http://www.tuxgirl.com signature.asc Description: Digital signature ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss
Re: [Ldsoss] Scout Tracking
--- Tom Welch [EMAIL PROTECTED] wrote: I used TroopMaster in the past and it did not require me to purchase a new license each year. However that was about 3 years ago and they may have changed their pricing plan. The biggest problem that I had with TroopMaster was that it is not easy to share with the next scout master that comes into the calling. At the Church we are looking at sponsoring an open source project around scouting. Any interested people that would like to work on such a program? Tom TroopMaster changed their licensing to a subscription model with the new major version release last year. The upgrade price for users of old versions gets a 3 year subscription. I'd be interested in working on an open source troop management program, particularly if it worked on multiple platforms. I've run TroopMaster successfully under Wine on Linux and Virtual PC on OS X, but I'd love to have something native :) - Gary PGP Key ID: 071B173D Fingerprint: ED30 B048 6833 56B4 28C0 CE52 F12B 884A 071B 173D ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss
RE: [Ldsoss] Scout Tracking
Hi there, That might work for LDS groups, but I doubt that other faiths want to use that website. Unless it is under the umbrella of BSA. Manfred -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tom Welch Sent: Tuesday, June 06, 2006 8:43 AM To: LDS Open Source Software Subject: Re: [Ldsoss] Scout Tracking Slide wrote: What would be great is if you could also have a plug-in type system for working with the various religious awards as well (Duty to God for LDS) which would then allow other Scouting groups to take advantage of it without tying it to just LDS Scouting. Yes, DTG is on the map to integrate into this program. The thoughts were to create some kind of a web based application so that parents, scout leaders and boys can all work together. -- Tom Welch [EMAIL PROTECTED] (801) 240-1609 (858) 829-4614 - Cell -- NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. -- ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss
Re: [Ldsoss] Scout Tracking
This is interesting to me, though I don't know I have the skills needed to help much unless it's LAMP.If the church were to sponsor an Open Source project, would it be likely a good idea to have it web-browser-based with the church sponsoring a main installation, kind of like phpGedView and John Finlay's pgvhosting.net?Tom HawsOn 6/6/06, Slide [EMAIL PROTECTED] wrote:I would definitely be interested in helping on an open source project. It might not intercept my Ward's current need, but it might in thefuture and it will help other units out. What would be great is if youcould also have a plug-in type system for working with the variousreligious awards as well (Duty to God for LDS) which would then allow other Scouting groups to take advantage of it without tying it to justLDS Scouting./two_centsAlexOn 6/6/06, Bryan Murdock [EMAIL PROTECTED] wrote: On 6/6/06, Tom Welch [EMAIL PROTECTED] wrote: I used TroopMaster in the past and it did not require me to purchase a new license each year.However that was about 3 years ago and they may have changed their pricing plan.The biggest problem that I had with TroopMaster was that it is not easy to share with the next scout master that comes into the calling. At the Church we are looking at sponsoring an open source project around scouting.Any interested people that would like to work on such a program? I'm interested.When I was scoutmaster the complete lack of a decent free application really bothered me.It shouldn't be that hard.In fact, I have the embarrassing little beginnings of a desktop scout tracking application here: http://ctm.sourceforge.net/ Mostly vaporware.I was too busy as scoutmaster to work on it, and now that I'm doing something else I sadly haven't had enough motivation to do much with it in a long while.I really think anything done needs to allow easy collaboration between scoutmaster, assistant scoutmaster, committee chair, even boys and their parents. That's where existing scout tracking software really fails.I searched high and low and there isn't much out there, especially open source.Here's the most active open source project: http://www.jaynorth.net/?view=scouttracker I believe the author has posted to this list before. Also along these lines has anyone see what the BSA is doing with this: https://scoutnet.scouting.org/iadv/UI/Home/ I haven't tracked down my ward's unit ID yet, so I haven't been able to check it out. There is another project that does most of what I figured an online scout tracking application should do here: http://etrailtoeagle.com I don't like that it's not free or open source though. Bryan ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss___Ldsoss mailing listLdsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss-- Tom Haws 480-201-5476OpenOffice.org v. MS Office:Kids love OOo.Wife didn't notice I switched.Get OOo free. There are many causes that I am prepared to die for but no causes that I am prepared to kill for Gandhi ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss
RE: [Ldsoss] Scout Tracking
Good point! ;) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dan Hanks Sent: Tuesday, June 06, 2006 9:04 AM To: LDS Open Source Software Subject: Re: [Ldsoss] Scout Tracking On Tue, 6 Jun 2006, Tom Welch wrote: could also have a plug-in type system for working with the various religious awards as well (Duty to God for LDS) which would then allow other Scouting groups to take advantage of it without tying it to just LDS Scouting. Yes, DTG is on the map to integrate into this program. The thoughts were to create some kind of a web based application so that parents, scout leaders and boys can all work together. Web-based would be great, but with the church's policy on non-official websites, where does that put the local unit that would want to install and use such a web-based app? -- Dan -- Tom Welch [EMAIL PROTECTED] (801) 240-1609 (858) 829-4614 - Cell -- NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. -- ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss
Re: [Ldsoss] Scout Tracking
--- Tom Welch [EMAIL PROTECTED] wrote: Dan Hanks wrote: On Tue, 6 Jun 2006, Tom Welch wrote: could also have a plug-in type system for working with the various religious awards as well (Duty to God for LDS) which would then allow other Scouting groups to take advantage of it without tying it to just LDS Scouting. Yes, DTG is on the map to integrate into this program. The thoughts were to create some kind of a web based application so that parents, scout leaders and boys can all work together. Web-based would be great, but with the church's policy on non-official websites, where does that put the local unit that would want to install and use such a web-based app? -- Dan These are issues that are currently being debated. More soon! Tom I have a couple of other concerns with a web-based app. One, of course, is the privacy and security issue. Do we want to create an application where we (in theory, at least) need to have signed permission forms from all of the parents, because we're putting their kids' information online? Password access controls are all fine and good, but the concern doesn't go away. There's also the issue of portability, by which I mean physical portability, not cross-platform portability. Running TroopMaster in Virtual PC is a bit of a pain, but having it on my Powerbook when I go to meetings with the Scoutmaster, the committee or the parents (regardless of the absence of an internet connection in the meeting) is half the value of using it in the first place. Granted, I could easily install a LAMP app on my Powerbook, too, but should that be necessary? - Gary PGP Key ID: 071B173D Fingerprint: ED30 B048 6833 56B4 28C0 CE52 F12B 884A 071B 173D ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss
Re: [Ldsoss] Scout Tracking
My thoughts were to create a central repository (whether hosted by the church or individually would be up for debate) and then we could provide several ways to access that data. 1. We (the community) could provide a SOAP or other interface to the data so that people could write thick client applications and synchronize their data with the central repository. I've actually done this quite successfully with some other applications and it works VERY well. So you can run independent of the server but when you go "back online" you can "sync" your data. If a person chose to never "work online" that would work fine as well. 2. We could create an application that only runs on a local machine but has good import/export capability so you can share your data with a new scout master or leader. This approach would not have the collaboration features but solves the privacy issues. Tom Gary Thornock wrote: --- Tom Welch [EMAIL PROTECTED] wrote: Dan Hanks wrote: On Tue, 6 Jun 2006, Tom Welch wrote: could also have a plug-in type system for working with the various religious awards as well (Duty to God for LDS) which would then allow other Scouting groups to take advantage of it without tying it to just LDS Scouting. Yes, DTG is on the map to integrate into this program. The thoughts were to create some kind of a web based application so that parents, scout leaders and boys can all work together. Web-based would be great, but with the church's policy on non-official websites, where does that put the local unit that would want to install and use such a web-based app? -- Dan These are issues that are currently being debated. More soon! Tom I have a couple of other concerns with a web-based app. One, of course, is the privacy and security issue. Do we want to create an application where we (in theory, at least) need to have signed permission forms from all of the parents, because we're putting their kids' information online? Password access controls are all fine and good, but the concern doesn't go away. There's also the issue of portability, by which I mean physical portability, not cross-platform portability. Running TroopMaster in Virtual PC is a bit of a pain, but having it on my Powerbook when I go to meetings with the Scoutmaster, the committee or the parents (regardless of the absence of an internet connection in the meeting) is half the value of using it in the first place. Granted, I could easily install a LAMP app on my Powerbook, too, but should that be necessary? - Gary PGP Key ID: 071B173D Fingerprint: ED30 B048 6833 56B4 28C0 CE52 F12B 884A 071B 173D ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss -- Tom Welch [EMAIL PROTECTED] (801) 240-1609 (858) 829-4614 - Cell --
RE: [Ldsoss] Scout Tracking
Hi Gary, Actually I think without wanting to start a legal debate about it this would be covered by you as a parent allowing your kids to be entered in the MIS already. Manfred. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gary Thornock Sent: Tuesday, June 06, 2006 10:29 AM To: LDS Open Source Software Subject: Re: [Ldsoss] Scout Tracking --- Tom Welch [EMAIL PROTECTED] wrote: Dan Hanks wrote: On Tue, 6 Jun 2006, Tom Welch wrote: could also have a plug-in type system for working with the various religious awards as well (Duty to God for LDS) which would then allow other Scouting groups to take advantage of it without tying it to just LDS Scouting. Yes, DTG is on the map to integrate into this program. The thoughts were to create some kind of a web based application so that parents, scout leaders and boys can all work together. Web-based would be great, but with the church's policy on non-official websites, where does that put the local unit that would want to install and use such a web-based app? -- Dan These are issues that are currently being debated. More soon! Tom I have a couple of other concerns with a web-based app. One, of course, is the privacy and security issue. Do we want to create an application where we (in theory, at least) need to have signed permission forms from all of the parents, because we're putting their kids' information online? Password access controls are all fine and good, but the concern doesn't go away. There's also the issue of portability, by which I mean physical portability, not cross-platform portability. Running TroopMaster in Virtual PC is a bit of a pain, but having it on my Powerbook when I go to meetings with the Scoutmaster, the committee or the parents (regardless of the absence of an internet connection in the meeting) is half the value of using it in the first place. Granted, I could easily install a LAMP app on my Powerbook, too, but should that be necessary? - Gary PGP Key ID: 071B173D Fingerprint: ED30 B048 6833 56B4 28C0 CE52 F12B 884A 071B 173D ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss
Re: [Ldsoss] Scout Tracking
On 6/6/06, Tom Welch [EMAIL PROTECTED] wrote: My thoughts were to create a central repository (whether hosted by the church or individually would be up for debate) and then we could provide several ways to access that data. 1. We (the community) could provide a SOAP or other interface to the data so that people could write thick client applications and synchronize their data with the central repository. I've actually done this quite successfully with some other applications and it works VERY well. So you can run independent of the server but when you go back online you can sync your data. If a person chose to never work online that would work fine as well. If you have read my sourceforge project vaporware description that's exactly the road I was thinking of starting down. Committee meetings and scoutmaster conferences are two of the places where the tracking software would be very helpful, but connectivity likely not available. I wonder if a think client is even necessary. Could the web application offer a csv file of data for download that could be edited with excel or oocalc and then re-uploaded? Bryan ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss
Re: [Ldsoss] Scout Tracking
On Tue, 6 Jun 2006, Tom Welch wrote: My thoughts were to create a central repository (whether hosted by the church or individually would be up for debate) and then we could provide several ways to access that data. 1. We (the community) could provide a SOAP or other interface to the data so that people could write thick client applications and synchronize their data with the central repository. I've actually done this quite successfully with some other applications and it works VERY well. So you can run independent of the server but when you go back online you can sync your data. If a person chose to never work online that would work fine as well. Oh yeah, this has my vote! Follow the CVS/SVN model. I 'checkout' a snapshot of the latest data with my local client. I take my laptop to the committee meeting, informal meetup with the boy/girl and their parents, or whatever, and input any updates I find. Once I'm back online I login and 'commit' any local changes I've made. If a central web-app were provided by the church, who hosted the data repository, and provided an API into the data, then parents and leaders can use the web-app to see everyone's progress. The community could then build various means of downloading/updating/etc that data. The Palm/handheld crowd could have their clients, the Perl folks (woohoo!) could make Net::LDS::ScoutTrack, and build whatever apps on top of that, the Java folks could do their thing, as could the Python folks. And Bishop, bless his heart, just has to login to the church's web-app to see where everyone is at. Sounds good to me :-). ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss
