New post
AllAccepted answers
Robert Cemper · Oct 3, 2023

Hi @Raj Singh,  @Lorenzo Scalese , @Evgeny Shvarov 

  • I'm fully for developer-to-developer initiatives.
    • though in practice, this is too often developer-to-nirvana 
    •   
  • dark-corner:   
    • several months back I suggested having an ARCHIVE option
    • so that packages stay in OEX but don't show up in the directory 
    • if not explicitly requested similar to SPAM in DC.  
    •  
  • But something like this seems to exist already.
    • My recent update of my OEX web sniffer found 2 packages
    • that do NOT show up in directory.
    • don't ask me how this works but that tool is there somehow.  
    •  
  • The actual critical corners might be identified by a combination of
    • LastUpdate in OEX and pending PR.
    • >>  

 

Robert Cemper · Sep 23, 2023

Sorry, there is a bug:

from config.py:

# Default config variables
import json
import os
import sys
import base64

APP_PATH = os.path.dirname(os.path.abspath(__file__))
JSON_CONFIG_PATH = APP_PATH+"/config.b64"
.....

BUT it is missing in your repo:

irisowner@2bbb2b066320:~/dev$ irispython ./rh/flask/main.py
/home/irisowner/dev/rh/flask/app/config.b64 not found

Ooops !


 

Robert Cemper · Sep 18, 2023

No discussion: Business Operation and Outbound adapter is a combination you should not break 

But to trigger a second Business OP You just need a Business Service that you kick,
no need for a Busines Process in between. Old ENSDEMO shows such examples.
eg. DemoRecodMapper

Here the FileService is the driving part.
another example uses a service that triggers itself DemoDashboard

It just lives on his timeout setting
Here it has nothing to do then updating some properties
But it could be anything. eg Kicking another Business Operation

Robert Cemper · Sep 15, 2023

Translation from the French community posted by @Lorenzo Scalese 
----------------------------------------------------------------------------------------------------------------

Hi,

ISC should keep a copy of the original repo until a new release on OEX (this is eventually the case already)
If a package gets orphaned, it seems to be complicated to hand it over to another member of the community if this copy doesn't exist. 

The account on GitHub could have been closed or the repo could have been deleted. This complicates the situation. We could. of course, try to recover the content from ZPM. But this could be wuite a huge effort of re-engineering. [ If it is available in ZPM at all. -rcc]

Regarding the deletion of the package.
I'm not against the idea, IF there is a valid reason.
It happened to me that I deleted a package because a new functionality of IRIS made it obsolete.
Anyhow, I left the repo on GitHub public in order not to lose the contained knowledge.

In that case, we could decide on an option to "archive" the package 
Not everybody works with the latest version of IRIS. So this might be interesting in some cases.

----------------------------------------------------------------------------------------------------------------
Thank you & Merci @Lorenzo Scalese 
 

Robert Cemper · Sep 14, 2023

You can see 2 examples of the adoption of orphaned  OEX packages here:

Besides the pure bug fixes, I applied some other enhancements for comfort

  • pointer to the orphaned predecessor
  • fixed Dockerfile to be version-independent
  • fixed pending mapping of SuperServer
  • added support for IPM
  • added installation guide
  • added quality tag
  • added demo server
  • added screenshots
  • enhanced README

Case #1) https://openexchange.intersystems.com/package/JSONExportManyToMany
GitHub:  https://github.com/rcemper/JSONExport-ManyToMany-AD

Case #2) https://openexchange.intersystems.com/package/Samples-FHIR-Oximeter-Devices
GitHub:  https://github.com/rcemper/Samples-FHIR-Oximeter-Devices-AD

The packages on OEX are still pending for approval and not public yet.

Robert Cemper · Sep 9, 2023

Today I had to process a rather sad exercise. 😢

For about 15 recognized packages in OEX I had to cancel my previous reviews
because the packages were broken. 
They could have been fixéd easily as there were PRs ready.
But for more than 3 months these fixes were just ignored by their owners.

On top of it:
A significant part of them was highly awarded in previous contests

I'm deeply disappointed, as the Quality of Packages in OEX was a personal focus.
However, I have to accept that quality has lost importance also in this
narrow section of my life.

😞