dhis2-devs team mailing list archive

[Jason Pickering <jason.p.pickering@xxxxxxxxx>]

Ccing dev list again.
--
Sent from my mobile
On Jan 4, 2012 1:25 PM, "Jason Pickering" <jason.p.pickering@xxxxxxxxx>
wrote:

>
> Adding to the devs list.
>
> Long andnings discussed this briefly this morning. Data appears to be
> transmitted and persisted but results in the "Whoops" exception page. The
> mobile client does not return an "uploaded successful " message. Defiently
> a bug it would seem but not blocking at the moment, at least according to a
> brief report from. Senegal.
>
> --
> Sent from my mobile
> On Jan 3, 2012 12:20 PM, "Lars Kristian Roland" <lars@xxxxxxxxx> wrote:
>
>> Long said he thought it wasn't working any more. But he would check again
>> and also look at what short term fixes could be done.
>>
>> If it works, that's very good.
>>
>> There have been some changes in program tracking that may have broken the
>> program tracking client, but the required fixes may not be very large.
>>
>> The goal however has to be to reach a stable and more robust protocol
>> that we can rely on for a while now + support GPRS based auto-update.
>>
>> Is the Senegal server in production now?
>>
>> What are the differences between the Senegal branch and trunk?
>>
>> Lars
>>
>> On 03.01.2012 12:06, Jason Pickering wrote:
>>
>>> Are you sure the current facility client do not work on 2.6? I have
>>> upgraded the Senegalese install to 2.6 but have not noticed any issues.
>>> Of course the protocol needs work but I was snot aware the current
>>> clients and server were not compatible. I did some basic testing the
>>> other day after the upgrade and it seemed to work for the facility
>>> client from the Senegal mobile client branch.
>>>
>>> Regards,
>>> Jason
>>>
>>> --
>>> Sent from my mobile
>>>
>>> On Jan 3, 2012 11:29 AM, "Lars Kristian Roland" <lars@xxxxxxxxx
>>> <mailto:lars@xxxxxxxxx>> wrote:
>>>
>>>    Jo has left. We need to focus on prioritizing the right tasks for
>>>      the mobile work. The below is quite important to read, as the
>>>    decisions may affect some of you and what we support in the future.
>>>
>>>    The J2ME clients do currently NOT work on 2.6. We propose to fix
>>>    this by implementing an improved protocol, rather than just doing a
>>>    quickfix.
>>>
>>>    The main task to be done is the new protocol for J2ME. There are a
>>>    number of reasons why we need this. The open issue now is who should
>>>    work in implementing this, in addition to Long.
>>>
>>>      - It needs to be more robust. Currently fails for HTTP 200 that
>>>    comes from operator's interrupted messages.
>>>      - Multiple version support simultaneously?? Need protocol
>>> versioning.
>>>      - Update procedure? HTTP check of the desired version. Version X.Y
>>>    (X=major, Y=minor) If X doesn't match, force update. If Y doesn't
>>>    match, offer to update but do not force. Update by starting up web
>>>    browser and downloading
>>>    new JAR.
>>>      - Tracking and aggregate reporting currently share the same API.
>>>    Should these be separate?
>>>
>>>    There are some other tasks (non-protocol) that also need handling:
>>>
>>>    - SMS out (Program tracking needs alerts, completeness report on SMS)
>>>    - SMS in (We hope to avoid using SMS as a transport for J2ME from
>>>    now on. We hope to phase it out. SMS in may be relevant for other
>>>    things, like simple plain SMS messages for registration/enrollement
>>>    etc. This can be on the roadmap for the future. )
>>>    - Zambia/Senegal (Mobile usage reimbursing project. Not started yet.
>>>    Long will discuss with Jason on this. Make sure Knut and mobilars
>>>    are in the email loop. Make sure Long is in Vietnam when Kristin and
>>>    Knut are in Vietnam. )
>>>    - Both tracking and aggregate J2ME client reporting is broken in 2.6.
>>>    - Syri pilot things???
>>>
>>>    Conclusions:
>>>    - New protocol is high priority. We need to find out who will
>>>    implement the server side. Long will have to work on both
>>>    server/clients side, but may need some help on this.
>>>    - Long will check if J2ME-broken-in-2.6 is a small fix, if so, he'll
>>>    do the fix. If not, we will not fix J2ME client for 2.6 (need to
>>>    tell everybody about this to make sure there no issues).
>>>
>>>
>>>    - SMS in protocol will no longer be supported from J2ME
>>>    - Master students will work on SMS out for messaging,
>>>    report/completeness alerts and program tracking alerts.
>>>    - J2ME program tracking is required for Uganda (March???)
>>>    - J2ME facility reporting is required for updated Punjab client
>>>    (early summer???)
>>>    - J2ME facility reporting is required for Zambia/Senegal (needs
>>>    update for reliability due to HTTP 200 issue)
>>>
>>>
>>>
>>>
>>