Time for next Community meetup.
This friday at 2pm (EST) ( See in your local timezone here )
meeting link https://meet.google.com/nqy-cyra-twc
If the meetings gets bigger, we should have a fixed agenda.
But for now, I want to get a feel for what people actually want to talk about, so I’m leaving it open, feel free to give suggestions for topics below.
Here is something i would like to talk about.
I’ve spent some time on OpenRPA again ( been at least a year since I last gave that some love ) and my thoughts a racing around how to create the next version OpenRPA.
- Could find some UI workflow framework for .net core, replace workflow foundation with that, and then upgrade to higher .net version.
- Could remove all UI from the different OpenRPA components ( plugins ) and then create a separate UI for OpenRPA in either electron or inside a webpage.
- Dig deeper into the underlying framework behind elsa workflow and try to “stay true” to workflow foundation.
- Separate chrome/browser automation from everything else in OpenRPA. Basically make the chrome extension connect to OpenFlow instead of OpenRPA and then add a basic recorder and workflow engine inside the chrome extension. ( think Automa or pixiebrix but more tightly integrated with openflow )
I have a favorite, but there is pros and cons with all
- is probably going to be the fastest thing to do. It will also force OpenRPA a to be a windows only application. It’s not the most important thing in the world, but both image recognition and browser automation could, run on any operating system, and browser automation most often is much better done inside docker. With something that is cross platform, we could also add support for action/Apple scripting on macos, DBus or similar on linux etc.
- This is my favorite. But is also going to take the longest time, and i fear many users will never “get it” and understand how it works. But it will be soooooo powerful and flexible. The idea is to split everything up to small packages that then connects to a central place using proto buffers. Each package can be written in the language that makes sense for it, so .net, python, nodejs etc.
This will make it much easier to support anything. It will also allow for crazy things like remote recording. And it will allow for being truly cross platform.
Lastly, this will fit perfectly into my package/agent framework in openflow. So going down this route will make OpenRPA a package of Openflow and no longer a “stand alone” product that just happen to also support talking with openflow. - I guess this is a variation of 1, except it will be much much faster to do the upgrade. It could potentially also allow for easy upgrading OpenRPA xaml workflows to the new framework. But will still have all the drawbacks as in 1. and re-add a heavy dependency to something that might “go away” or be “unsupported” just like workflow foundation did. This is my least favorite solution, but is worth mentioning.
- Is really not an option, since i could do this either way. And i really want to. It has been on my todo list for the last 2 years, of something i really, really would like to do/add. But I keep pushing it, till I also know what the future of OpenRPA should be, since it might make sense to “merge” the two. ( ie. use the same workflow engine for both the chrome extension and OpenRPA )