IRC Chat : 2010-10-05 - OpenMRS

00:06:12 *** misha680 has quit IRC
00:08:30 *** agdak has quit IRC
00:29:10 *** misha680 has joined #openmrs
01:05:26 *** earsareclosed has joined #openmrs
01:07:03 <earsareclosed> I am trying to used the linkage code in the reginstrief trunk but I need an xml based linkage file, but i don't see anything that tells me the format or gives me an example. Can someone please help me
01:35:51 <bwolfe> earsareclosed: hmm, no one here has worked on that
01:36:10 <bwolfe> earsareclosed: you might get some luck if you send an email to the dev mailing list
01:50:18 *** earsareclosed has quit IRC
02:07:16 <OpenMRSBot> Recent updates in the world of openmrs: New Changeset: OpenMRS trunk #15724: [wyclif] Adding more javadocs from code review, see CR-TRUNK-141 <http://feedproxy.google.com/~r/OMRStrunk/~3/5_EJCAzs8tI/> || New Changeset: OpenMRS trunk #15723: [mseaton] Change to liquibase update warning message for ticket TRUNK-24 following code review comments CR-TRUNK-104 <http://feedproxy.google.com/~r/OMRStrunk/~3/HGTTsyaQx7U/>
03:05:26 *** bwolfe has quit IRC
03:11:26 <OpenMRSBot> Recent updates in the world of openmrs: New Changeset: OpenMRS trunk #15726: [wyclif] Undoing an erroneous text change to fix unit test - TRUNK-417 <http://feedproxy.google.com/~r/OMRStrunk/~3/g8f03PjwlYg/>
05:29:05 *** fixl has joined #openmrs
06:14:04 *** robota has joined #openmrs
06:48:33 *** Pkirwa has joined #openmrs
07:41:43 *** Hazamonzo_ has quit IRC
07:41:54 *** Hazamonzo_ has joined #openmrs
07:45:50 *** Pkirwa has quit IRC
08:00:37 *** Pkirwa has joined #openmrs
08:06:04 *** robota has quit IRC
08:06:50 *** robota has joined #openmrs
08:23:24 *** Temi has joined #openmrs
08:24:00 <Temi> @anyone: How can we deploy on the web?
08:24:22 <Temi> @anyone: How can we deploy on the web?
08:24:32 <Temi> Please, help out
08:30:59 *** Temi has quit IRC
08:34:58 *** robota has quit IRC
08:35:24 *** robota has joined #openmrs
11:12:21 *** tinashe has joined #openmrs
11:12:49 *** tinashe has left #openmrs
11:15:03 *** tinashe has joined #openmrs
11:15:10 *** tinashe has left #openmrs
11:48:02 *** noobie_ has joined #openmrs
11:48:08 <noobie_> hi
11:48:18 <noobie_> anybody there ?
11:48:34 <noobie_> :'(
11:52:54 *** bwolfe has joined #openmrs
11:52:54 *** ChanServ sets mode: +o bwolfe
12:01:47 *** noobie_ has quit IRC
13:06:17 *** wyclif has quit IRC
13:36:27 *** wyclif has joined #openmrs
13:54:40 *** mblanchette has joined #openmrs
14:10:59 *** MalteF has joined #openmrs
14:10:59 *** ChanServ sets mode: +v MalteF
14:20:32 *** robota has quit IRC
14:53:48 *** Pkirwa has quit IRC
15:08:29 *** wyclif has quit IRC
15:23:14 *** wyclif has joined #openmrs
15:25:09 <OpenMRSBot> Recent updates in the world of openmrs: OpenMRS Forum: Re: Concept dictionary errors <http://forum.openmrs.org/viewtopic.php?f=23&t=687#p2620> || OpenMRS Forum: Search Function for Diagnosis <http://forum.openmrs.org/viewtopic.php?f=3&t=692#p2619>
15:31:39 *** fixl has quit IRC
15:45:13 *** fixl has joined #openmrs
15:48:03 *** misha680 has quit IRC
15:57:23 <OpenMRSBot> Recent updates in the world of openmrs: OpenMRS Forum: Re: Search Function for Diagnosis <http://forum.openmrs.org/viewtopic.php?f=3&t=692#p2621>
16:20:27 *** misha680 has joined #openmrs
16:22:23 *** wyclif has quit IRC
16:29:24 <OpenMRSBot> Recent updates in the world of openmrs: New Changeset: OpenMRS trunk #15753: [wyclif] PatientSetService.getEncounters(Cohort patients) does not return all Encounters - TRUNK-429 <http://feedproxy.google.com/~r/OMRStrunk/~3/eb4AFgUAIKg/>
16:45:03 *** fixl has quit IRC
17:17:08 *** earsareclosed has joined #openmrs
17:47:31 *** wyclif has joined #openmrs
18:20:52 *** Pkirwa has joined #openmrs
18:35:45 *** wyclif has quit IRC
18:41:34 *** wyclif has joined #openmrs
18:55:57 *** wyclif has quit IRC
18:58:18 *** wyclif has joined #openmrs
19:30:49 *** Pkirwa has quit IRC
20:05:33 *** mblanchette has quit IRC
20:08:26 *** earsareclosed has quit IRC
20:42:52 *** MalteF has quit IRC
21:02:07 *** Hazamonzo_ has quit IRC
21:47:57 <OpenMRSBot> Recent updates in the world of openmrs: New Changeset: OpenMRS trunk #15765: [bwolfe] Add optional init paramter to specify location of application data directory - TRUNK-1779 Author: misha680 <http://feedproxy.google.com/~r/OMRStrunk/~3/eO5ZEghxsfk/>
22:05:14 *** wyclif has quit IRC
22:28:14 *** agdak has joined #openmrs
22:28:41 <agdak> bwolfe: does the implementation of openmrs still run on tomcat or has it been moved to jetty
22:33:29 <bwolfe> agdak: implementations still run tomcat usually
22:33:44 <bwolfe> although they can use jetty or glassfish or any other servlet container if they want to
22:48:20 <OpenMRSBot> Recent updates in the world of openmrs: New Changeset: OpenMRS trunk #15767: [wyclif] Search for patient by ID number is slow - TRUNK-1616 <http://feedproxy.google.com/~r/OMRStrunk/~3/lRoEEFm9dOk/>
23:03:08 <agdak> bwolfe: when compiling and deploying the server where is the .war located i tried looking for it and couldn't find it and it seems i have to compile openmrs each time i turn off and on my computer
23:03:55 <bwolfe> agdak: which target are you using ?
23:04:14 <bwolfe> agdak: jetty:run depends on the "compile" target, so it compiles first then uses that war to run in jetty
23:04:28 <bwolfe> agdak: there should be an openmrs.war in the /webapp/target directory
23:04:28 <agdak> bwolfe: i use jetty:run
23:05:39 <agdak> bwolfe: nope i don't see it
23:05:59 *** tinashe has joined #openmrs
23:06:16 <bwolfe> agdak: do a refresh of that folder
23:06:30 <tinashe> hi Ben..can we go onto pm...
23:06:47 <agdak> bwolfe: did that
23:06:50 *** misha680 has quit IRC
23:07:16 <agdak> bwolfe: still not seeing it i also did a search from the terminal for the openmrs.war and it couldn't find it
23:07:23 <bwolfe> tinashe: pm is fine if you have specific questions. but I prefer general questions be here in the open forum for others to benefit as well
23:08:03 <tinashe> bwolfe, ok...just wanted to update you on the what i have done so far..
23:08:38 <bwolfe> agdak: hmm, perhaps jetty removes it again when shutting down?
23:09:18 <agdak> bwolfe: that is what i thought and i thought i could start it using the java -jar start.jar but that doesn't work
23:09:30 <tinashe> bwolfe, I have been looking around using perl, python, and php in scripting the database write-to process of the Atlas module..
23:10:06 <tinashe> bwolfe, and eventually used java to write to the database...
23:10:18 <agdak> bwolfe: each time i have only been successful in deploying openmrs when compiling the whole source code and having eclipse run jetty and all
23:10:20 <tinashe> would that be appropriate to use...
23:11:04 <bwolfe> agdak: no, the jar doesn't run standalone. there might be a way to just compile the war and then use tomcat or something else
23:11:28 <agdak> ah gotcha
23:12:19 <bwolfe> tinashe: hmm, ok. we only have a few servers that run a servlet container
23:13:25 <tinashe> bwolfe, before we go into that, had a suggestion on sending these stats....my thinking is...
23:14:28 <tinashe> bwolfe, for people without internet connectivity, they have to have an option to save or pull out saved statistics as well from some temporary storage, in say xml format..
23:15:19 <tinashe> bwolfe, then at the main server, the scripts functions in two ways....interpreting stats on files, and those which come directly from the module's scheduler...
23:15:28 <bwolfe> tinashe: ok, but that is low priority
23:15:44 <bwolfe> I figure there will be limited people that are willing to download/upload the file
23:17:05 <tinashe> understood..so does this imply saving the data temporarily to a local openmrs database then the scheduler does the rest along the uptime of an OpenMRS implementation...
23:17:44 <bwolfe> tinashe: could do that, but again, if there is no internet I was envisioning it just ignoring the upload
23:17:50 <bwolfe> have you coded that up already?
23:19:45 <tinashe> what i have coded up so far is not much, just a registration page of the provider (optional) to fill in demographics info and check which "metadata" they intend to send to the OpenMRS server, and currently, i just coded up saving that data to a local seperate database...which
23:20:26 <tinashe> essentially represents the database which will temporarily or locally store the stats and provider information before sending all details and stats to the server...
23:21:19 <tinashe> is this in line with how this should be developed/designed...
23:22:03 <bwolfe> tinashe: if by local separate database you mean a table in the openmrs database, yes, thats fine
23:22:22 <bwolfe> tinashe: you can write a ScheduledTask that tries to upload things once a week or so
23:23:00 <bwolfe> the FormEntry module has a ScheduledTask in it. and there is a "ping google" ScheduledTask in trunk that you can look at
23:26:11 <tinashe> bwolfe, will look into that...on that note..i would like to ask on how i can develop/implement against receiving data from the module's scheduler, and also...would redirecting a provider just after registration to the stats module show some kind of better combination of these modules, so that that function can start collecting the metadata to be exported as well as give an option of the scheduler's interval...
23:27:34 <bwolfe> tinashe: what do you mean just after registration? and what do you mean the two modules integration? are you writing a separate one or are you in the quickstats one?
23:29:27 <tinashe> bwolfe, i mean after registration to submitting OpenMRS stats to openmrs.org, and there is a feel around not merging the modules (which i know you gave a go ahead)...
23:29:47 <tinashe> to be one module...
23:32:16 <bwolfe> tinashe: I figured the link to register/share would be from the stats page. or from the admin page
23:32:44 <bwolfe> there doesn't need to be a redirect to the stats page after saving their registration info
23:34:55 <tinashe> ok...will develop that as two admin pages...was just thinking once a provider registers, then they can proceed to share the "metadata"
23:35:12 <tinashe> and then everything else lies to the scheduler...
23:36:42 <tinashe> which brings my final question for the day...
23:37:36 <tinashe> bwolfe, has there been any suggestions on how the stats data is going to be gathered on the stats server
23:38:31 <tinashe> this would be quite handy to me testing the scheduler and getting to have some possible design of the receiving point..
23:39:05 <tinashe> unless if i go up to sending the stats data only...
23:40:33 <bwolfe> tinashe: hmm
23:40:42 <bwolfe> I assuem the stats will be shown in graphs
23:41:06 <bwolfe> similar to how the quickstats module does it. perhaps "total obs in all installations" "average obs in each installation", etc
23:41:21 <bwolfe> "number of installations", "average installations per country"
23:42:55 *** misha680 has joined #openmrs
23:43:21 <tinashe> bwolfe, so is that functionality part of what i am developing as well, since, essentially the quick-stats module is complete...just have to store the provider details, and stats into a table in openmrs db...
23:43:44 <tinashe> plus scheduler to send the data..
23:45:33 <bwolfe> tinashe: sure, you can write that too. :-)
23:46:11 <bwolfe> its less openmrs-like and more of a custom one-off task, so you might want to put that off. you could write all the java/module stuff and we make another task for someone with php knowledge to do the server side
23:49:14 <tinashe> ok...that was related to how i can test the full functionality of the module's scheduler when i finish developing within the module...as a suggestion....would a direct database write to a remote native database be ok in terms of testing if the module's scheduler sends data correctly..
23:49:16 <bwolfe> you could just worry about POSTing to a server with a certain address and with certain parameters
23:49:36 <bwolfe> tinashe: yeah, thats fine
23:51:52 <tinashe> ok...so for this version...would be thorough testing be necessary, i,e, already registered users, duplicate "metadata" statistics (or same data over time periods) e.g. modules and versions etc..
23:52:25 <tinashe> or that will be handled at the server side...
23:58:17 <tinashe> bwolfe, what i mean is that the scheduler can for example keep on sending same modules and versions on the scheduled intervals..which does not really reflect true statistics...