HT/VT Web Site

[nbflint]

Also open-source with enough developers means that projects won't stagnate.

Just for clarity sake, it should be plainly stated that this would not be an open source project. The code would be developed by volunteers and owned by the church. The volunteers would not have liberty to use the code for any other purposes.

That said and understood the open source model would provide the security and conveniences this type of project would need.

[WelchTC]

Just for clarity sake, it should be plainly stated that this would not be an open source project. The code would be developed by volunteers and owned by the church. The volunteers would not have liberty to use the code for any other purposes.

That said and understood the open source model would provide the security and conveniences this type of project would need.

We have not made any decisions (should we proceed with this project) if we would release the code to the community or not. Personally I can't see much value of having it "open source" as I don't know who would make derivative works from it.

Tom

[brado426]

Tom:

I'm not sure if this justifies a new post or is along the lines of what you are looking for in this thread. A comment you made in another thread brings up a point.

A community member working on an outsourced project for the church would need an adequate test environment at their home. Therefore, some instructions or possibly even tools would need to be made available to these community developers.

The thing that jumped out at me is when you mentioned that the church mostly uses Oracle for a back-end database. I have used Oracle at work for a couple development projects, but we mostly use MS SQL. I can get an MS SQL server set up easily because I have done it many times and Microsoft provides a free watered-down version to developers. Though I have done some development with Oracle, I have never set up an Oracle server... nor do I know whether a free version that matches the same version that the church uses is even available to run at home for development purposes.

In the case of the HT/VT Reporting site that I have been working on, it could be made to work with a Web Service to acquire and submit church data, but even then it would still require a back-end database of its own.

The point I am trying to make is that community members would need to be provided with clear documentation that describes how a test environment must be configured including DB server version/Java Version/Microsoft .NET Framework version, etc. Also, the community members would need to somehow have access to all the tools and development licenses that they need.

Brad O.

[marlattrj-p40]

The community members wouldn't need a DB server running on their own computer. The church would just need to create secure dynamic XML pages (example http://www.lds.org/data.php?key=k234ksd ... t=06234522) which require a specific key to access them much like the Google Maps API. Community developers could use AJAX to work with the content thus the data would stay secure and every one would have an even playing field for testing and developing.


Rich

[marlattrj-p40]

... XML pages (example http://www.lds.org/data.php?key=k234ksd ... t=06234522) which require a specific key to access ...

FYI this is just a fake URL I created as an example. -Rich

[Mr. M-p40]

Nothing finds flaws in applications faster than saying, "This application is secure."

You could release a test db and access calls and just require a week of community testing before any applications could be developed. Then use the honor system.

[marlattrj-p40]

Nothing finds flaws in applications faster than saying, "This application is secure."

I absolutely agree with you.
I was just suggesting that keys could be assigned to community developers, and that they could allow access to an API that outputs XML pages from the church DB. The nice thing about that would be that the church could control what they wanted to provide as public info and developers could use that data for development. XML is very nice to work with, a developer can make calls to a dynamic XML page using AJAX and create very nice applications.

[brado426]

I was just suggesting that keys could be assigned to community developers, and that they could allow access to an API that outputs XML pages from the church DB. The nice thing about that would be that the church could control what they wanted to provide as public info and developers could use that data for development. XML is very nice to work with, a developer can make calls to a dynamic XML page using AJAX and create very nice applications.

That sounds a lot like a .NET Web Service. I think that is a good way to exchange data between one system and another (for example accessing information in church systems), but I'm not so sure it is a good idea for an application to be designed to function solely using this technology.

I am wondering how hard it would be for the developer to modify the back-end database schema when doing it this way? Also, wouldn't there would be significant overhead running an entire application based on XML data feeds. Additionally, as a developer, I prefer to have full access to the application's database that I am working on... otherwise I think things would take much longer.

Perhaps I'm only apprehensive about it only because I've never done it before and I do not know of anyone that is doing it.

Brad O.

[marlattrj-p40]

That sounds a lot like a .NET Web Service. I think that is a good way to exchange data between one system and another (for example accessing information in church systems), but for some reason I'm not so sure it is a good idea for an application to be designed to function solely using this technology.

AJAX is not just a .NET method, in fact you don't need .NET at all. AJAX stands for Asynchronous JavaScript and XML, it is a method that allows websites to transfer data back and forth without requiring the page to be refreshed. which can greatly speed up web application as it you no longer have to reload an entire page. This is done using the XMLHttpRequest object in javascript sending and receiving data asynchronously. XML is the typical type of data that is exchanged although any format will work, including preformatted HTML, plain text, JSON, etc. These files can be created dynamically by some form of server-side scripting.

Most web apps are moving this direction (ie, Yahoo, Google, etc) due to the speed and and flexibility. I would think that the church would also want to start going in this direction as well.

I am wondering how hard it would be for the developer to modify the back-end database schema when doing it this way? Also, wouldn't there would be significant overhead running an entire application based on XML data feeds. Additionally, as a developer, I prefer to have full access to the application's database that I am working on... otherwise I think things would take much longer.

At first developers would need to work with the church to developed DB schema, but remember the data can be retrieved using a dynamic server-side script. so for instance the web page can call for a specific unit by passing the unit number and then pass other criteria to the server, the server would then send back a formated XML document with that units data for the page to read. I would suggest looking into this it is very slick.

I suggested this as a posible answer to Tom's first question, "How do we securely integrate this into internal systems here at the Church that are currently under development without exposing sensitive and critical data to the community....", this would give the church control over what data they allow to be accessed by the community.

[brado426]

AJAX is not just a .NET method, in fact you don't need .NET at all. AJAX stands for Asynchronous JavaScript and XML.

I was just comparing it to a .NET WebService.... I didn't mean that I thought .NET was required. I know that AJAX libraries have only been recently made available for .NET.

I think I understand what you are suggesting. I don't think I have enough experience with it to comment further though.

Brad O.