Thanks everyone for your contributions to that discussion 
@danielle I agree with you, that’s why I put it as draft as there are already lots of wishlist items so I was trying to synthetize the needs from those wishlist items. But I agree that to move it forward, EVEN IF the solution was to build the API we would do it bit by bit for specific cases. So I propose to move that one back to wishlist (or integration, could be both) and reactivate the discussion and evolution of the POS case: Enable hubs to use OFN to record retail (onsite) sales [POS] (that I will put back as “draft” until we agree that the need is clearly understood).
So on this draft icebox we can start brainstorming solutions. We did it in Australia but it seems things have changed, Rob got rid of his home made POS and went for Odoo, etc.
In brainstorming solutions, there are basically 3 main solutions for each of the "needs" listed above:
1- Develop it ourselves inside OFN. Which leads to the question: where do we draw the line of what OFN does and where we integrate with others? If we want to do too many things, we won’t do anything properly… I think there is some form of consent on this from the previous discussions. But still that’s always a possible answer to the above needs.
2- Develop a specific connector to integrate with a specific external system. For instance @oeoeaio has built some "script" to integrate OFN and Odoo POS. Zapier is a form of connector that @lin_d_hop has developped between OFN and Google Sheet to build custom reports and dashboards.
2.1 That connector can directly call the database. That’s what we do today with Zapier and some manual scripts. This can be a quick patch but present a certain number of risks on the long run:
-
if external system directly connect to DB, if we decide to change the DB they will be impacted, and we might not know exactly who uses our DB data for what: can you imagine the process of changing a DB that everyone (from outside) is accessing with their integrations
-
external systems consuming data directly from DB could involve random load on a production database so performance issue (ex: users will write the wrong SQL query and break our prod database)
-
there can be data security issues
-
each new specific system we want to integrate with will require a specific connector.
So it is quicker, but it’s like a patch, it’s not a long term solution, and it is highly problematic on a long term.
2.2 Or it can consume the API. So you can still use easy to set up connectors like Zapier, but they consume the API and not directly the DB.
-
it requires the API to exist of course so it takes a bit more time and investment on short term
-
but it’s much more scalable, less security issue, it’s easier to maintain and manage the API than all the separate random integration plugged directly to database, easier to profile the clients: know exactly what clients are doing what in our API, etc.
3- Clean and refine the OFN API so that it can be used for that specific use case, but to connect with any external system. It means a bit more investment as said above, but there is already something, we don’t start from scratch. We can use unmet needs to step by step build our API and consume it to answer the need. It seems like the only reasonable path for a long term strategy. it can be used with or without an integrator tool like Zapier. A dev could deploy Odoo and connect through both APIs OFN and Odoo for a specific user who needs POS (on a short term).
SO I think, and we discuss sometimes with @luisramos0 about it, that on how to answer all the needs above, we need a clearly affirmed strategy. That will drive the choice we make among all the possible solutions. Sitting where I am, I see 3, eventually combined with 2.2 as a valid strategy. I’m not a tech, but I’m working on some projects with other platform coops on interoperability and that’s the direction all platforms are going toward. If we don’t go that way, we are going to miss the train.
I stop here and will continue on the specific POS use case to move forward on a concrete case.