question: is there a way to get events' results that can be captured in server, for example by `Rule`?

[mstfdkmn]

For example, say as an admin I defined a pep rule to capture the path of an object that is uploaded by iCommands, an if a PRC user (rodsuser) would somehow like to get this information, how can this be possible? I tried a bit to capture it with the Rule class but no success. More specifically what I wanted to achieve:

• define a pep in core.py to capture the path of the file uploaded
• save it in memory (with a method of a class)
• define a rule that will get what is stored in memory
• call said rule with the PRC
• can I expect to see output of that rule (what it returns or sdtout) in the client script?

p.s.: this is just a question for now.

[trel]

If you write down the information in the iRODS namespace where the other user can see it ... then yes?

Otherwise, different requests should not be able to communicate via memory.

Is that what you're asking?

[mstfdkmn]

Thanks, yes that is I think what I need. However some more thoughts:

As known, event based policy implementations are possible through the enforcement points/PEPs in the server side (and mostly this is system wide) and this requires naturally involvement of administrators (write/deploy rules), and also depending on the task type, this might cause an overload in the irods server. Moreover, I guess this time to time a bit restricts users to use their own compute, special environments etc.

So I was searching to find a way that can give a possibility to users to write their own scripts/policy implementations using event results captured in the irods server. This was the aim of the question.

As for your suggestion "write down the information in the iRODS namespace", in your opinion which of the following would be a better option for users who will intaract wiht the PRC?

• attaching this information as metadata on an irods entity (a user/collection/data object),
• or writing the information in a file that users can read.

[trel]

the considerations are permissions and collisions...

• if you want to write for another user, then either the data object OR the data object / collection with the AVUs must be readable by the other user
• if you want to write multiple types of messages, then consider the namespace collisions you'll need to manage.

An AVU-based solution will allow more direct access via genquery - rather than reading a file in some format, and then parsing it on the client-side. But the AVU-based solution may be limiting if you're hoping to write lengthy messages or want to limit visibility to specific other users, different from the permissions on an object itself.

I think each option could be better - depending on the use case.

[mstfdkmn]

Thanks closing this.