some questions about the current MoTeCH platform
Bruce MacLeod
efforts for the platform functionality of MoTeCH and I thought I might
raise a few questions that might help us clarify the upcoming work.
1) Should we adopt conventions for naming and package content ?
A) Is there a convention (or should we adopt one) for the content
of the package that has the same names as the module ?
EventKeys ?, OSGi Activator ?, EventHandlers ?
Constants ? Exceptions ?
(EventKeys appear in different locations ... scheduletracking,
or not at all : ivr module)
B) Should there be a convention for the packages in a module ?
Service ? DAO ? Domain (or Model) ? Builder ? Web ? Exception ?
TAMA puts event handlers in listener package, mobileforms
module puts it in a callbacks, etc
C) Are there logging conventions/responsibilities for event
handlers ?
all events that get "relayed" are logged. Should all events
that get handled be logged ?
are the logged events the way to get a global picture of all
module interactions and message flow ?
D) Can we clarify the desired content of module names with api,
common, or base-name ? What are the guidelines ?
ie, motech-platform-decisiontree versus motech-platform-
decisiontree-common
both have a ...server.decisiontree package
no classes in motech-platform-server, pill-reminder only has
an activator
Do we have a clear reason for naming some modules api and not
others ?
if a module produces events, does api obscure the event
communication mechanism ?
what are the different responsibilities of server-api and
platform-common ?
2) Are we comfortable with the current model information that is part
of all applications ?
current model is in org.motechproject.model in motech-platform-
common
rules should be out
ScheduleJob classes ?
does every application need to build its model from the ground
up ?
recipient (id, phone #) ? User, Roles ? other core model
classes ?
if so, should we establish a relationship between patient and
receipent ? (composition ?)
even a basic demo has to define the recipient, the dao for that
recipient and mapping to CouchDB
3) Should we have a MoTeCH common platform module ?
TAMA does not use it ... why not ?
Should we be building up the capabilities of the common-platform
model
Why hasn't the BASE64Decoder error message in
org.motechproject.util been fixed ?
4) What is the best practice way to get a reference to services in
another module ?
what is our strategy for modules ? OSGi ?
What was the results of the OSGi spike ?
maven static linking, Context object, look-up OSGi services ?
5) Why is there an Alerts module & many of the same alert concepts
embedded in the domain package of schedule-tracking ?
TAMA-Web uses the Alerts module ... maybe no refactoring of
schedule-tracking ?
should the platform have a single notion of alert ?
6) Are TAMA, Ghana-National, ... using the platform code on
Google ?
I could not find the other projects on Google
7) Are we doing an adequate job of maintaining platform functionality
while developing implementations ?
is the work done with dates/time in the platform ?
does the authentication work in TAMA help the platform, .....
8) Should org.motechproject.ivr.asterisk (in motech-platform-ivr) be
moved to a module ?
Rob LaRubbio
On 12/05/2011 11:17 AM, Bruce MacLeod wrote:
> 1) Should we adopt conventions for naming and package content ?
>
We should, but a lot of the existing packages listed below could go away
or change once we complete the OSGi changes and have a proper way of
loading interfaces to services that are loaded into the OSGi context.
> A) Is there a convention (or should we adopt one) for the content
> of the package that has the same names as the module ?
>
> EventKeys ?, OSGi Activator ?, EventHandlers ?
>
> Constants ? Exceptions ?
>
> (EventKeys appear in different locations ... scheduletracking,
> or not at all : ivr module)
>
> B) Should there be a convention for the packages in a module ?
>
> Service ? DAO ? Domain (or Model) ? Builder ? Web ? Exception ?
>
> TAMA puts event handlers in listener package, mobileforms
> module puts it in a callbacks, etc
>
>
> C) Are there logging conventions/responsibilities for event
> handlers ?
We certainly want to have detailed logging within the platform, so
logging all actions taken makes sense. I also would really like to see
more instrumentation put in place. I added a metrics logging framework
early on and we should get in the habit of measuring everything we can
within the platform so it is easy to monitor and improve the performance
of the system
> all events that get "relayed" are logged. Should all events
> that get handled be logged ?
>
> are the logged events the way to get a global picture of all
> module interactions and message flow ?
>
> D) Can we clarify the desired content of module names with api,
> common, or base-name ? What are the guidelines ?
At the start the API platform was meant to be portable. So it could be
executed within the platform or in an external system as a remote API to
the platform. I forget the exact idea behind common, but I think it was
meant to hold packages used by multiple server modules.
>
> ie, motech-platform-decisiontree versus motech-platform-
> decisiontree-common
> both have a ...server.decisiontree package
>
> no classes in motech-platform-server, pill-reminder only has
> an activator
>
> Do we have a clear reason for naming some modules api and not
> others ?
>
> if a module produces events, does api obscure the event
> communication mechanism ?
>
> what are the different responsibilities of server-api and
> platform-common ?
>
> 2) Are we comfortable with the current model information that is part
> of all applications ?
>
> current model is in org.motechproject.model in motech-platform-
> common
>
> rules should be out
>
> ScheduleJob classes ?
>
> does every application need to build its model from the ground
> up ?
From the ground up, no, but I don't think there should be a model baked
into the platform. Instead we should have multiple model modules that
an application can install and use as a starting point and built off of.
>
> recipient (id, phone #) ? User, Roles ? other core model
> classes ?
> if so, should we establish a relationship between patient and
> receipent ? (composition ?)
>
> even a basic demo has to define the recipient, the dao for that
> recipient and mapping to CouchDB
>
> 3) Should we have a MoTeCH common platform module ?
>
> TAMA does not use it ... why not ?
I think TAMA does use it.
>
> Should we be building up the capabilities of the common-platform
> model
>
> Why hasn't the BASE64Decoder error message in
> org.motechproject.util been fixed ?
What error message?
>
> 4) What is the best practice way to get a reference to services in
> another module ?
This depends on the final decision around the OSGi system, if you have
thoughts or a proposal I think it would be great to hear it as a
starting point.
>
> what is our strategy for modules ? OSGi ?
>
> What was the results of the OSGi spike ?
>
> maven static linking, Context object, look-up OSGi services ?
>
> 5) Why is there an Alerts module& many of the same alert concepts
> embedded in the domain package of schedule-tracking ?
>
> TAMA-Web uses the Alerts module ... maybe no refactoring of
> schedule-tracking ?
>
> should the platform have a single notion of alert ?
The Alerts modules used by TAMA-Web and the alerts in schedule tracking
are different and aim to handle different use cases. This is just a
terminology issues that we went back and forth on but never settled on a
good name. Within TAMA and the Alerts module it is meant to be for
alerts raised within a dashboard. That module provides the ability to
target an alert at a single user, or a group of users. Any user can
then acknowledge the alert. So think of a monitoring dashboard with the
alert signaling that some action needs to be taken. With schedule
tracking the alert is really just an event that makes the transition
from one time window (care upcoming) to another (care past due). The
response to that alert could be an SMS or using the Alert module to
notify a nurse via a dashboard.
>
> 6) Are TAMA, Ghana-National, ... using the platform code on
> Google ?
>
> I could not find the other projects on Google
No other projects are currently on google. (Although they might migrate
or move to private repositories on github). The other projects should
be using the platform via the artifacts we release to nexus, not using
the code directly.
>
> 7) Are we doing an adequate job of maintaining platform functionality
> while developing implementations ?
>
> is the work done with dates/time in the platform ?
> does the authentication work in TAMA help the platform, .....
>
> 8) Should org.motechproject.ivr.asterisk (in motech-platform-ivr) be
> moved to a module ?
Yes, it was written early on before the pluggable ivr concept was
introduced.
-Rob