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