[15.0][ADD] web_widget_remote_measure: New module

[chienandalu]

cc @Tecnativa TT38745

ping @carlosdauden

Example of behavior in the oncoming stock_remote_device:

[pedrobaeza]

Being web client implementation, I think it should be called web_widget_remote_measure or similar.

[chienandalu]

Ok, changed :)

[pedrobaeza]

I wonder the overlap with https://odoo-community.org/shop/remote-base-3251?search=remote#attr=21539 and indeed seeing this code, it's including in the same module the base definition with the widget.

[pedrobaeza]

This is also a very specific "remote" thing, so maybe including websocket reference or something can be convenient.

[chienandalu]

I wonder the overlap with https://odoo-community.org/shop/remote-base-3251?search=remote#attr=21539 and indeed seeing this code, it's including in the same module the base definition with the widget.

I'd say that module's purpose is to store the accesses to the Odoo server

[chienandalu]

This is also a very specific "remote" thing, so maybe including websocket reference or something can be convenient.

It can be extended to a Webservices interface in the future if needed

[pedrobaeza]

Then remote_webservice prefix?

[chienandalu]

But it could be either webservices or websockets

[pedrobaeza]

OK, I don't insist then.

[rousseldenis]

And why not envisaging connecting devices like IOT (that could be connected to POS) and more specifically to pywebdriver ?

That allows you to implement protocols there. With the advantage of being available for all flows you want.

[chienandalu]

And why not envisaging connecting devices like IOT (that could be connected to POS) and more specifically to pywebdriver ?
That allows you to implement protocols there. With the advantage of being available for all flows you want.

Connection to any remote measure device (IoT or the device itself via web services) would be possible if implemented but we want to keep the infrastructure required to implement this in the customer's setup as simple as possible.

For our current approach, adding an IoT (or pywebdriver) in the middle is an extra point of potential failure that can complicate our maintenance.

[rousseldenis]

And why not envisaging connecting devices like IOT (that could be connected to POS) and more specifically to pywebdriver ?
That allows you to implement protocols there. With the advantage of being available for all flows you want.

Connection to any remote measure device (IoT or the device itself via web services) would be possible if implemented but we want to keep the infrastructure required to implement this in the customer's setup as simple as possible.

For our current approach, adding an IoT (or pywebdriver) in the middle is an extra point of potential failure that can complicate our maintenance.

So, implementing a particular protocol should maybe go in another module

[bosd]

Let us know when you're ready

[pedrobaeza]

/ocabot merge nobump

[OCA-git-bot]

What a great day to merge this nice PR. Let's do it!
Prepared branch 15.0-ocabot-merge-pr-2407-by-pedrobaeza-bump-nobump, awaiting test results.

[OCA-git-bot]

This PR has the approved label and has been created more than 5 days ago. It should therefore be ready to merge by a maintainer (or a PSC member if the concerned addon has no declared maintainer). 🤖

[OCA-git-bot]

Congratulations, your PR was merged at db87b3b. Thanks a lot for contributing to OCA. ❤️