Skip to Main Content
HCL Domino Ideas Portal

Welcome to the #dominoforever Product Ideas Forum! The place where you can submit product ideas and enhancement request. We encourage you to participate by voting on, commenting on, and creating new ideas. All new ideas will be evaluated by HCL Product Management & Engineering teams, and the next steps will be communicated. While not all submitted ideas will be executed upon, community feedback will play a key role in influencing which ideas are and when they will be implemented.

For more information and upcoming events around #dominoforever, please visit our Destination Domino Page

Status Needs Clarification
Workspace Domino
Categories General
Created by Guest
Created on Dec 15, 2023

Optimize protocol for high latency networks

Protocol is very transaction oriented, and on high latency networks, clients work really slow, cause of a lot of transaction exchange. Some commands could be queued and processed in a batch and result returned. This would greatly improve responsivenes and speed of applications.

  • Attach files
  • Guest
    Reply
    |
    Apr 25, 2024

    Just send the user context (username, language, etc) , the action to process (Open Document, Action Button).

    Send it to some middleware component.

    This component is processing all steps, i.e. determine dialog list options, calculate computed for display fields, Refresh Document, HideWhenFormulas, ....

    Send the result as a whole back.

    This could be done, by sending results for each part action back to have the result like the transactional operations or as a whole document status result.

    If returned as transactional operation results, the client could just process the results in the order the middleware executed them (replay).

    If returned as a whole document status, the client just renders the results, without thinking about anything. (set fields with no events, and so on).


    So only one or maybe only a few requests have to be done instead of 50.


    Example:

    Form with 10 dialog Lists, 10 computed on display, 2 embedded Views.

    Instead of making 1 request for form design, 1 request for document data, 10 requests for dialog list options, 10 requests for computed on display Lookups, 2 requests for embedded view design, 2 requests for embedded view content, ...

    you would make one request: Open Document unid =xyz wit user context = abc

    Result = All results of the requests listed before aggregated by the middleware component on the server.

  • Admin
    Thomas Hampel
    Reply
    |
    Jan 5, 2024

    How should this work if your (custom) application is developed to perform lots of transactions against a remote server? The client only does what your application was coded for.