# Call for Suggestions: OpenMRS Platform 3.0.0 **URL:** \ **Category:** Development\ **Tags:** platform, platform-3x\ **Created:** [August 28, 2025, 11:21am UTC](https://talk.openmrs.org/t/call-for-suggestions-openmrs-platform-3-0-0/46965 "2025-08-28T11:21:42Z")\ **Posts on this page:** 13\ **Page:** 2
**Author:** ![raff](https://talk.openmrs.org/user_avatar/talk.openmrs.org/raff/32/11894_2.png) [@raff](https://talk.openmrs.org/u/raff)\ **Post date:** [September 11, 2025, 11:57am UTC](https://talk.openmrs.org/t/call-for-suggestions-openmrs-platform-3-0-0/46965/21 "2025-09-11T11:57:44Z")
@mseaton created [TRUNK-6429](https://openmrs.atlassian.net/browse/TRUNK-6429) ---
**Author:** ![wikumc](https://talk.openmrs.org/user_avatar/talk.openmrs.org/wikumc/32/21813_2.png) [@wikumc](https://talk.openmrs.org/u/wikumc)\ **Post date:** [September 23, 2025, 6:30am UTC](https://talk.openmrs.org/t/call-for-suggestions-openmrs-platform-3-0-0/46965/22 "2025-09-23T06:30:14Z")
We received these two suggestions during the OpenMRS platform 3.x unconference session last week. - **Tasks** (schedulers), ensuring the schedules actually run. - **Queue** management moving into the core. cc: @slubwama, @mherman22 ---
**Author:** ![dkayiwa](https://talk.openmrs.org/user_avatar/talk.openmrs.org/dkayiwa/32/179_2.png) [@dkayiwa](https://talk.openmrs.org/u/dkayiwa)\ **Post date:** [September 23, 2025, 9:30am UTC](https://talk.openmrs.org/t/call-for-suggestions-openmrs-platform-3-0-0/46965/23 "2025-09-23T09:30:24Z")
@wikumc too summarised for those who did not attend to understand what is really involved. 😃 ---
**Author:** ![wikumc](https://talk.openmrs.org/user_avatar/talk.openmrs.org/wikumc/32/21813_2.png) [@wikumc](https://talk.openmrs.org/u/wikumc)\ **Post date:** [September 23, 2025, 11:01am UTC](https://talk.openmrs.org/t/call-for-suggestions-openmrs-platform-3-0-0/46965/24 "2025-09-23T11:01:05Z")
Both of these ideas came from @slubwama, and I think he’ll be able to elaborate on them further. The entire session was recorded, so a video should be available soon for anyone who missed it. In the meantime, you can go through the meeting notes here: > **[Documentation - OpenMRS Wiki](https://openmrs.atlassian.net/wiki/spaces/docs/pages/596508727)** ---
**Author:** ![ibacher](https://talk.openmrs.org/user_avatar/talk.openmrs.org/ibacher/32/19751_2.png) [@ibacher](https://talk.openmrs.org/u/ibacher)\ **Post date:** [September 23, 2025, 6:30pm UTC](https://talk.openmrs.org/t/call-for-suggestions-openmrs-platform-3-0-0/46965/25 "2025-09-23T18:30:17Z")
Another additional thought: For metadata we always have a “name“ field, but this is only a single value. We have kind of a hack around this via the “display“ property in REST in FHIR, but this a [display-only hack](https://github.com/openmrs/openmrs-module-webservices.rest/blob/7b4c006ce6c3e617529f37dd399649110856c853/omod-common/src/main/java/org/openmrs/module/webservices/rest/web/resource/impl/DelegatingCrudResource.java#L305), so that these resources cannot be, for example, searched via these keys. It would be great if it Platform 3.0, metadata supported per-locale names. ---
**Author:** ![dkayiwa](https://talk.openmrs.org/user_avatar/talk.openmrs.org/dkayiwa/32/179_2.png) [@dkayiwa](https://talk.openmrs.org/u/dkayiwa)\ **Post date:** [September 24, 2025, 6:21pm UTC](https://talk.openmrs.org/t/call-for-suggestions-openmrs-platform-3-0-0/46965/26 "2025-09-24T18:21:03Z")
From @joeldenning In exploring server rendering of esm apps for O3, there is a question of whether to use NodeJS or a Java-based ecmascript engine. > > > In exploring server rendering of esm apps for O3, there is a question of whether… to use NodeJS or a Java-based ecmascript engine. > > The Rhino project is one I learned about a long time ago as a possible option. Would a Java module using Rhino be preferred for the Openmrs ecosystem rather than a separate NodeJS process? > > https://en.m.wikipedia.org/wiki/Rhino\_(JavaScript\_engine) > > cc @dkayiwa who collaborated on this module at the beginning ---
**Author:** ![ibacher](https://talk.openmrs.org/user_avatar/talk.openmrs.org/ibacher/32/19751_2.png) [@ibacher](https://talk.openmrs.org/u/ibacher)\ **Post date:** [September 25, 2025, 2:57pm UTC](https://talk.openmrs.org/t/call-for-suggestions-openmrs-platform-3-0-0/46965/27 "2025-09-25T14:57:02Z")
Yet another set of things: 1. For fields in the database that store a timestamp, we should convert to using fields that use timestamp with timezone information, so that datetimes are representable unambiguously in the database. 2. For fields that are stored as dates (birthdates without times; observations that take a date value), we should support storing these as simple dates, most likely as strings without being a Date object. ---
**Author:** ![tendomart](https://talk.openmrs.org/user_avatar/talk.openmrs.org/tendomart/32/6753_2.png) [@tendomart](https://talk.openmrs.org/u/tendomart)\ **Post date:** [September 25, 2025, 8:20pm UTC](https://talk.openmrs.org/t/call-for-suggestions-openmrs-platform-3-0-0/46965/28 "2025-09-25T20:20:23Z")
> [@dkayiwa](#): > > From @joeldenning In exploring server rendering of esm apps for O3, there is a question of whether to use NodeJS or a Java-based ecmascript engine. Would this mean less burden on computing resources and complete mitigation of managing volatile Node versions and package managers since JS runtime will now be moved into Java-based ecmascript engines like GraalJs or Nashorn ? hence only managing a single run time for both Java and JS ? ---
**Author:** ![samuel34](https://talk.openmrs.org/user_avatar/talk.openmrs.org/samuel34/32/17813_2.png) [@samuel34](https://talk.openmrs.org/u/samuel34)\ **Post date:** [September 26, 2025, 7:45am UTC](https://talk.openmrs.org/t/call-for-suggestions-openmrs-platform-3-0-0/46965/29 "2025-09-26T07:45:09Z")
> [@tendomart](#): > > volatile Node versions and package managers since JS runtime will now be moved into Java-based ecmascript engines like GraalJs or Nashon ? Currently in O3, we don’t support SSR; when it comes to the RefApp, our frontend container is basically an nginx server, serving all bundled ESM files to the client for CSR. We’re looking for an ideal SSR option to improve initial load performance (e.g faster first paint, better support for low-powered devices). The still question stands, should we opt for a JVM JS runtime or separate Node process? ---
**Author:** ![tendomart](https://talk.openmrs.org/user_avatar/talk.openmrs.org/tendomart/32/6753_2.png) [@tendomart](https://talk.openmrs.org/u/tendomart)\ **Post date:** [September 26, 2025, 8:10am UTC](https://talk.openmrs.org/t/call-for-suggestions-openmrs-platform-3-0-0/46965/30 "2025-09-26T08:10:00Z")
> [@samuel34](#): > > SSR Ooh yeah, thanks for this. And hey @samuel34 what’s the better way to find it than testing out those options, doing SSR for 03 via GraalJS, since .. (Since **Nashorn is deprecated** ) anyways looks like the past is catching up again, i’d think of having an option for both approaches to run parallel for performance testing purposes then a consensus reached .. Imagine a world where we are back at just installing a single JDK for platform and still leveraging the power of our esms. What am not yet sure of, what happens when the runtime goes down ? it may mean the entire ship sinks 😄 > **[React SSR on JVM using GraalVM](https://dkovalenko.net/react-ssr-graalvm/)** > > Do you want to do Server-Side Rendering(SSR) of a React app on the JVM? > **[Run GraalJS on a Stock JDK](https://www.graalvm.org/latest/reference-manual/js/RunOnJDK/)** > > GraalVM is an advanced JDK with ahead-of-time Native Image compilation. > **[JavaScript](https://www.graalvm.org/javascript/)** > > GraalVM is an advanced JDK with ahead-of-time Native Image compilation. ---
**Author:** ![dkayiwa](https://talk.openmrs.org/user_avatar/talk.openmrs.org/dkayiwa/32/179_2.png) [@dkayiwa](https://talk.openmrs.org/u/dkayiwa)\ **Post date:** [September 26, 2025, 10:06am UTC](https://talk.openmrs.org/t/call-for-suggestions-openmrs-platform-3-0-0/46965/31 "2025-09-26T10:06:00Z")
The performance complaints that i have always heard about O3, have not been the initial load time. And therefore, i personally feel that adding SSR is not worth the effort. At least not yet. 🙂 ---
**Author:** ![ibacher](https://talk.openmrs.org/user_avatar/talk.openmrs.org/ibacher/32/19751_2.png) [@ibacher](https://talk.openmrs.org/u/ibacher)\ **Post date:** [September 26, 2025, 2:57pm UTC](https://talk.openmrs.org/t/call-for-suggestions-openmrs-platform-3-0-0/46965/32 "2025-09-26T14:57:45Z")
> [@samuel34](#): > > The still question stands, should we opt for a JVM JS runtime or separate Node process? I just want to point out that the entire question of SSR is completely orthogonal to Platform 3.0. Even if we need to completely re-write module-spa to support it, that’s something that can be done with or without platform updates. ---
**Author:** ![mksd](https://talk.openmrs.org/user_avatar/talk.openmrs.org/mksd/32/11729_2.png) [@mksd](https://talk.openmrs.org/u/mksd)\ **Post date:** [September 29, 2025, 6:14am UTC](https://talk.openmrs.org/t/call-for-suggestions-openmrs-platform-3-0-0/46965/33 "2025-09-29T06:14:30Z")
> [@ibacher](#): > > For fields in the database that store a timestamp, we should convert to using fields that use timestamp with timezone information, so that datetimes are representable unambiguously in the database. +1 to that! Having dealt with the timezone issue in the past, I can say it is essential, especially for centralized (cloud) deployments, which are becoming increasingly common. [Previous page](https://talk.openmrs.org/t/call-for-suggestions-openmrs-platform-3-0-0/46965.md?page=1)