RE: [Ldsoss] Advancement tracker
Could we, please, step back and discuss requirements *before* we discuss these types of implementation technologies? Tom's requesting Java is one thing, as it's nearly ubiquitous for programmers, users, and platforms. It may not be your preference, but it does fit the bill. If we want general participation from the larger community (not just the LDSOSS list), then something more widely known is probably a good idea. As for databases, what are the database requirements? If the program operation is to be done at the ward level, then we're probably (depending on the ward size) talking about 30-150 kids or so. If at the stake, then multiply that by 8 or so. Are those numbers sufficient to warrant a database? If so, what type (not brand)? Granted, I'm not a DBA, but isn't a flat file faster for those numbers? Although I work in security and RD, these days, I was a once upon a time USAF Software Engineer and those 'managerial pre-architectural decisions' sometimes come back to haunt me... Steve -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tom Welch I've not used this framework so it may not be suitable. For the database, we could use Derby or One$DB. Again, I'm totally open to other ideas here. I would recommend that we ship with specific, small database, such as the two you refer to, but that as a design principle, we validate that we can easily install and run on one or more of the commercial caliber DB's such as MySQL. We could use hibernate which is somewhat DB agnostic. It does not officially support Derby or One$DB but reports are that it does work with Derby. I just wonder of hibernate would be somewhat overkill. ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss
Re: [Ldsoss] Advancement tracker
On 6/23/06, Steven H. McCown [EMAIL PROTECTED] wrote: As for databases, what are the database requirements?If the programoperation is to be done at the ward level, then we're probably (depending onthe ward size) talking about 30-150 kids or so.If at the stake, then multiply that by 8 or so.Are those numbers sufficient to warrant adatabase?If so, what type (not brand)?Granted, I'm not a DBA, but isn'ta flat file faster for those numbers?I think that's worth asking. Is the nature of advancement tracking such that it lends itself to 1 portable file per individual, whether that file be flat or xml-ish? Suppose leader is recording participation in a swim activity or hike or meeting, and a kid needs 12 such events to qualify for requirement 6a of the Athlete activity pin. Would it be appropriate to record the event id and date in his data file with the details on the event in the event log file? Would such an approach be something we would regret later? Pros: It's extremely portable, and could be even semi-readable by mere human parents moving out of the area.Cons:It's a proprietary hack.It doesn't seem very elegant.Tom Haws ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss
Re: [Ldsoss] Advancement tracker
Thomas Haws wrote: I think that's worth asking. Is the nature of advancement tracking such that it lends itself to 1 portable file per individual, whether that file be flat or xml-ish? ... Cons: It's a proprietary hack. It doesn't seem very elegant. Wait. Are you thinking that a flat file approach is a hack (and a proprietary one at that?) *And* it's not elegent? Admittedly, an xml file would not be very readable, but there are other formats that can be used for this (YAML, JSON come immediately to mind) that are human readable and easily understood by both a human and a program. And an individual file would make security very easy to implement--each user would have their own password which would be used to individually encrypt the files. Alan ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss
Re: [Ldsoss] Advancement tracker
Thomas Haws wrote: On 6/23/06, *Steven H. McCown* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: As for databases, what are the database requirements? If the program operation is to be done at the ward level, then we're probably (depending on the ward size) talking about 30-150 kids or so. If at the stake, then multiply that by 8 or so. Are those numbers sufficient to warrant a database? If so, what type (not brand)? Granted, I'm not a DBA, but isn't a flat file faster for those numbers? Excellent question. I doubt any would deny that for these numbers, some form of flat file would be sufficient. However, from a performance and sizing perspective, I don't think we'd see significant impact from an embedded database, such as Darby. Especially since Sun will be including an embedded database as part of the JDK in the next release of Java. From a security perspective, I'd rather store information in a database then in a flat file. That's a gut reaction, not an argument based strictly on technical merits. It just provides another layer of penetration that an intruder must breach to get to the data. If we use Darby's encryption capability to store the data, that would provide yet another layer of security. Long-term wise, I know that Steve and some others are not a proponents of an online solution, but if the BSA or a large BSA-Sponsor were to eventually host such a service, then scaling the solution would be simply a matter of swapping in an industrial grade database. Thomas Haws wrote: I think that's worth asking. Is the nature of advancement tracking such that it lends itself to 1 portable file per individual, whether that file be flat or xml-ish? Having the ability to export/import/print the data to flat files such as XML, CSV or report format would be a nice use-case to support. I'd argue that having the ability to export/import a single set of records for a specific individual is probably one of the primary use-cases that we would want to support. For example, a parent could install the Scout Tracker software on his/her personal desktop and sync with the troop's database, just like a disconnected scout leader. Generalizing this requirement suggests that the functional requirement would be that an authorized user should be able to view and download records that pertain to the scouts and the activities that are assigned to them. But, of course, they should ONLY be able to view/download assigned youth. Some possible actors for such a use-case would be: Individual Scout, Parent, Merit Badge Counselor, YM/YW leader, Advancement Coordinator, Assistant Scout Master, Scout Master, Eagle District Coordinator (?don't remember their real title). ex: A parent should be authorized to view, update and download only records of scouts/YW for which they are legal guardians. With this capability we have empowered not only the ward leaders, but the parent and child. -- A. Rick Anderson ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss
Re: [Ldsoss] Advancement tracker
Wait.Are you thinking that a flat file approach is a hack (and aproprietary one at that?)*And* it's not elegent? Did I say that? :-D . Blame it on my Wikpiedia background, I was arguing for the enemy, or trying to see the issue from all sides. I guess that makes it tough to know where I stand. But getting the right answer is far, far more important than where I happen to stand. Admittedly, an xml file would not be very readable, but there are otherformats that can be used for this (YAML, JSON come immediately to mind) that are human readable and easily understood by both a human and a program.And an individual file would make security very easy to implement--eachuser would have their own password which would be used to individually encrypt the files.I love it. Great ideas!!Tom Haws ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss
Re: [Ldsoss] Advancement tracker
A. Rick Anderson wrote: Tom Welch wrote: We could use the JPF (Java Plug-in Frameowkr found at http://jpf.sourceforge.net) for an arcitecture to allow us to make this system more modular. I am not seeing where scout tracking would need plug-in capability. Given the fact that the BSA changes advancement requirements periodically, hard-coding advancement criteria would seem to be short-sighted, and my inclination would be to go with a database driven approach. However, the requirement to support both thin clients and thick clients, would argue in favor of this type of framework. I'm thinking of a plugin framework so that others can write plugins (such as DTG or other things we haven't thought of yet). Someone suggested we use the eclipse plugin framework. I'll look into that as well. I've not used this framework so it may not be suitable. For the database, we could use Derby or One$DB. Again, I'm totally open to other ideas here. I would recommend that we ship with specific, small database, such as the two you refer to, but that as a design principle, we validate that we can easily install and run on one or more of the commercial caliber DB's such as MySQL. We could use hibernate which is somewhat DB agnostic. It does not officially support Derby or One$DB but reports are that it does work with Derby. I just wonder of hibernate would be somewhat overkill. I believe that there needs to be two different discussions. One from a technology perspective (which platform, technology, DB, etc) and then a Features discussion (look feel, type of information to track, etc). I'm in the process of setting up a wiki wherein we could all collaborate on these types of documents. I need another month for this to be complete. A mailing list may be faster to set up and would free up the bandwidth on this list. Could such a list be set up on the same server as this one? Yes it could. -- 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
Re: [Ldsoss] Advancement tracker
Tom Welch wrote: I don't have a lot of specifics in mind but here are some very general bullet points. * Needs to support both scout tracking with an option to add Duty to God. I understand that not everyone using this software would be a member but if we make this a plugin or option in the preferences to turn it on, that would be cool. * Model the software so it could easily be modified to support personal progress. * Have an online/offline mode so that people can run it locally but optionally synch up to a master repository. * optionally have a web interface to the data. I'm not a major scouting kind of guy so I'm not that familiar with all of the specifics a scouting program should have. From a technology perspective, I was thinking that java would be the way to go. From a personal perspective, this would be my preference. We could use the JPF (Java Plug-in Frameowkr found at http://jpf.sourceforge.net) for an arcitecture to allow us to make this system more modular. I am not seeing where scout tracking would need plug-in capability. Given the fact that the BSA changes advancement requirements periodically, hard-coding advancement criteria would seem to be short-sighted, and my inclination would be to go with a database driven approach. However, the requirement to support both thin clients and thick clients, would argue in favor of this type of framework. I've not used this framework so it may not be suitable. For the database, we could use Derby or One$DB. Again, I'm totally open to other ideas here. I would recommend that we ship with specific, small database, such as the two you refer to, but that as a design principle, we validate that we can easily install and run on one or more of the commercial caliber DB's such as MySQL. I believe that there needs to be two different discussions. One from a technology perspective (which platform, technology, DB, etc) and then a Features discussion (look feel, type of information to track, etc). I'm in the process of setting up a wiki wherein we could all collaborate on these types of documents. I need another month for this to be complete. A mailing list may be faster to set up and would free up the bandwidth on this list. Could such a list be set up on the same server as this one? -- A. Rick Anderson ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss
[Ldsoss] Advancement tracker
I'd like to think a little more about the first draft requirements of the Advancement Tracker Tom Welch asked about.Suppose one of us or some of us were starting on a shoestring, maybe at the SourceForge site offered. I am wondering, irrespective of the language, and obviously platform agnosticism is essential, what the inital stab at an open source Advancement tracker might want to look like to the end user. Should we start with a Troopmaster clone? Is that what Tom Welch has in mind?Then should we plan for possible connection/synchronization to a central repository a la MLS? And multiple languages and advancement programs? Tom Haws ___ Ldsoss mailing list Ldsoss@lists.ldsoss.org http://lists.ldsoss.org/mailman/listinfo/ldsoss
