Re: Cluster OpenMeetings For Single Access

[Aom Jeff Root]

Ok, thank you.

Le mer. 22 sept. 2021 à 22:13, Ali Alhaidary 
a écrit :

> Hi Jeffrey,
>
> Unfortunately, I am not the expert in that, however, I have CCed the
> user group where you can find help.
>
> Ali
>
> On 9/22/21 8:26 PM, Aom Jeff Root wrote:
> > Hi Mr Ali, I work on clustering openmeetings with two nodes and I want
> > to make single access to the group server. But I don't know how to;
> > Can I have help from you please ? Since I asked, I don't have a
> > response yet.
> >
> >
> > Kind regards,
> > Jeffrey.
>

Desktop share frame sizing

[Jeffry Johnson]

We are having issues with constant refresh of frame sizing when sharing
desktop streams. Where would we find the functions to set a fixed larger
frame size?

Re: [DISCUSS] Breaking JSON response body change in OpenMeetings Json/Rest API 7.0.0

[Ali Alhaidary]

Very good, as long as changes will not affect/impact all of those 
invested in OM of resources, and will not, all of a sudden, things will 
not work on a supposedly simple upgrade.


Ali

On 9/23/21 12:47 AM, seba.wag...@gmail.com wrote:

Hi all!

I think we may try to solve too many things at the same time in this 
discussion. But also in our API. It just seems things are a bit too 
tightly coupled.


For example:
*We can't change/update REST methods, cause they affect SOAP calls. 
Currently we have a just a single class that does both*
 => It was easy when the API was simple. But then over time it 
actually became harder, cause we discovered that under the covers Soap 
and Rest representation is different.


*We introduced REST 10years ago and the definitions of REST changed 
over time*
=> We created the OpenMeetings REST API over 10years(!!) ago. At that 
time the definition of REST was quite fluent. By now there is quite a 
different and more strict understanding of what Rest means. And how 
HTTP methods (GET/POST/PUT/DELETE), resource paths ( having nouns not 
verbs as resource paths, eg: /users/$identifier), using the right kind 
of request/response message structure or for example how 
authentication/security works.


Things have changed. And I actually think by now it is taking more 
time and effort to try to get Soap/Rest into 1 class. Then separating 
them. As well as it's just maybe a long time since we had a major uplift.


How about we do the following:

1) We keep the current SOAP/REST API structure as is
=> Minimise rework / No breaking changes
=> We accept some minor quirks around some _documentation only_ 
annotations in order to document it in a way people can use it


2) For v7.0.0 or v8.0.0 we introduce a v2 of the Rest API
But:
 => v2 is REST only. The existing/v1 API is the SOAP/REST API. And 
SOAP stays where it is. That way we have less work in trying to make 2 
things into 1.
 => Soap and Rest can still use the same "adapter" class in order to 
achieve 'feature parity'. But we do _not_ attempt for example that 
method parameters need to match
 => Having a single v2 REST only interface makes it also easier to 
write integration tests. Cause you only need to test the REST interface.
 => There isn't really any issue with the SOAP interface. SOAP hasn't 
changed in the last 10years. There isn't any need to go for a v2 in 
the SOAP API


3) We agree _before_ adding a v2 what REST "guidelines" we adopt
=> Instead of arguing what kind of HTTP method, security headers, POST 
body parameters we adopt a guideline/standard document. And simply 
comply with that standard.

=> This will also make it a lot easier to:
A) Integrate with it, cause people are used to the 
format/standard/guidelines and there is less discussion needed
B) The tooling will be much easier, because all the code generators, 
documentation tools, CXF-RS, json-mappers we are using are referencing 
a similar or same guidelines/standard. So we not constantly need to 
customise things to fit into how the existing OpenMeetings API works
An example of a REST guideline/standard that we could adopt is: 
OpenAPI 3.0.x (https://swagger.io/specification/ 
) + Restful recommendations 
(https://restfulapi.net/ )


@Maxim Solodovnik  what do you think? I 
think more than 10years is enough for a single version of an API. I 
think by now it actually is _less_ work to have a new v2 Rest only 
version of the API then trying to somehow create a SOAP/REST API and 
try to enhance that into a "RESTful" way but not break it at the same 
time.


Thanks,
Seb

Sebastian Wagner
Director Arrakeen Solutions, OM-Hosting.com
http://arrakeen-solutions.co.nz/ 
https://om-hosting.com  - Cloud & Server 
Hosting for HTML5 Video-Conferencing OpenMeetings




On Thu, 23 Sept 2021 at 02:24, Daniel Baker 
mailto:i...@collisiondetection.biz>> wrote:


Can you not employ an extra programmer?

On 22/09/2021 13:24, Maxim Solodovnik wrote:



On Wed, 22 Sept 2021 at 19:20, Ali Alhaidary
mailto:ali.alhaid...@the5stars.org>> wrote:


On 9/22/21 3:14 PM, Maxim Solodovnik wrote:

I only can do manual testing here :(

What is manual testing?


I'm installing everything
setting up integration and do clicking :)))


IMO these changes (if we will be able to do them) worth to
be done

what is IMO ?


In My Opinion :)


Why I raise some old design issues: we can do changes now
and let the API unchanged for another several years :)))

What is several years ;-)


Well I believe REST API was changed 2-3 times, so we are trying
to keep it stable
v1/v2 etc. appro

Re: Cluster OpenMeetings For Single Access

[Ali Alhaidary]

Hi Jeffrey,

Unfortunately, I am not the expert in that, however, I have CCed the 
user group where you can find help.


Ali

On 9/22/21 8:26 PM, Aom Jeff Root wrote:
Hi Mr Ali, I work on clustering openmeetings with two nodes and I want 
to make single access to the group server. But I don't know how to; 
Can I have help from you please ? Since I asked, I don't have a 
response yet.



Kind regards,
Jeffrey.

Re: [DISCUSS] Breaking JSON response body change in OpenMeetings Json/Rest API 7.0.0

[seba.wag...@gmail.com]

Hi all!

I think we may try to solve too many things at the same time in this
discussion. But also in our API. It just seems things are a bit too tightly
coupled.

For example:
*We can't change/update REST methods, cause they affect SOAP calls.
Currently we have a just a single class that does both*
 => It was easy when the API was simple. But then over time it actually
became harder, cause we discovered that under the covers Soap and Rest
representation is different.

*We introduced REST 10years ago and the definitions of REST changed over
time*
=> We created the OpenMeetings REST API over 10years(!!) ago. At that time
the definition of REST was quite fluent. By now there is quite a different
and more strict understanding of what Rest means. And how HTTP methods
(GET/POST/PUT/DELETE), resource paths ( having nouns not verbs as resource
paths, eg: /users/$identifier), using the right kind of
request/response message structure or for example how
authentication/security works.

Things have changed. And I actually think by now it is taking more time and
effort to try to get Soap/Rest into 1 class. Then separating them. As well
as it's just maybe a long time since we had a major uplift.

How about we do the following:

1) We keep the current SOAP/REST API structure as is
=> Minimise rework / No breaking changes
=> We accept some minor quirks around some *documentation only* annotations
in order to document it in a way people can use it

2) For v7.0.0 or v8.0.0 we introduce a v2 of the Rest API
But:
 => v2 is REST only. The existing/v1 API is the SOAP/REST API. And SOAP
stays where it is. That way we have less work in trying to make 2 things
into 1.
 => Soap and Rest can still use the same "adapter" class in order to
achieve 'feature parity'. But we do _not_ attempt for example that method
parameters need to match
 => Having a single v2 REST only interface makes it also easier to write
integration tests. Cause you only need to test the REST interface.
 => There isn't really any issue with the SOAP interface. SOAP hasn't
changed in the last 10years. There isn't any need to go for a v2 in the
SOAP API

3) We agree _before_ adding a v2 what REST "guidelines" we adopt
=> Instead of arguing what kind of HTTP method, security headers, POST body
parameters we adopt a guideline/standard document. And simply comply with
that standard.
=> This will also make it a lot easier to:
A) Integrate with it, cause people are used to the
format/standard/guidelines and there is less discussion needed
B) The tooling will be much easier, because all the code generators,
documentation tools, CXF-RS, json-mappers we are using are referencing a
similar or same guidelines/standard. So we not constantly need to customise
things to fit into how the existing OpenMeetings API works
An example of a REST guideline/standard that we could adopt is: OpenAPI
3.0.x (https://swagger.io/specification/) + Restful recommendations (
https://restfulapi.net/)

@Maxim Solodovnik  what do you think? I think more
than 10years is enough for a single version of an API. I think by now it
actually is _less_ work to have a new v2 Rest only version of the API then
trying to somehow create a SOAP/REST API and try to enhance that into a
"RESTful" way but not break it at the same time.

Thanks,
Seb

Sebastian Wagner
Director Arrakeen Solutions, OM-Hosting.com
http://arrakeen-solutions.co.nz/
https://om-hosting.com - Cloud & Server Hosting for HTML5
Video-Conferencing OpenMeetings




On Thu, 23 Sept 2021 at 02:24, Daniel Baker 
wrote:

> Can you not employ an extra programmer?
> On 22/09/2021 13:24, Maxim Solodovnik wrote:
>
>
>
> On Wed, 22 Sept 2021 at 19:20, Ali Alhaidary 
> wrote:
>
>>
>> On 9/22/21 3:14 PM, Maxim Solodovnik wrote:
>>
>> I only can do manual testing here :(
>>
>> What is manual testing?
>>
>
> I'm installing everything
> setting up integration and do clicking :)))
>
>
>> IMO these changes (if we will be able to do them) worth to be done
>>
>> what is IMO ?
>>
>
> In My Opinion :)
>
>> Why I raise some old design issues: we can do changes now and let the API
>> unchanged for another several years :)))
>>
>> What is several years ;-)
>>
>
> Well I believe REST API was changed 2-3 times, so we are trying to keep it
> stable
> v1/v2 etc. approach can also be applied
> the problem here: I don't have enough time to maintain more than one
> version :((
>
>
>> On Wed, 22 Sept 2021 at 19:09, Ali Alhaidary 
>> wrote:
>>
>>> The issue here is that, It is a lot of work, and, a lot of testing that
>>> follows. We are not a direct API users, however, moodle plugin is. Along
>>> the road, things could break in such change. So, if you see this change is
>>> the the way forward, I am in with as usual a dedicated production server
>>> for selected teaches/students as long as the old work (mainly rec

Re: Using OM with a drawing pad

[Erik Edwards]

Works well with Gaomon PD1161 when displayed on another screen.

The PD1161 has a built-in 1920x1080 monitor but the sense layer is not 
merged with the display so it requires a parallax calibration which it 
never gets correct. This is a tablet issue, not an OM issue.


Would be nice to see some more awareness in OM of tablet input, it only 
acts as a mouse.


On 9/22/21 11:49, jox joe wrote:

Is Openmettings working properly with a drawing pad/tablet?
Brands: Watcom, XP-PEN etc.
Has anyone tried this already?
Thank you.


OpenPGP_signature
Description: OpenPGP digital signature

Re: Using OM with a drawing pad

[Ali Alhaidary]

working beautifully good.

Ali

On 9/22/21 7:49 PM, jox joe wrote:

Is Openmettings working properly with a drawing pad/tablet?
Brands: Watcom, XP-PEN etc.
Has anyone tried this already?
Thank you.

Using OM with a drawing pad

[jox joe]

Is Openmettings working properly with a drawing pad/tablet?
Brands: Watcom, XP-PEN etc.
Has anyone tried this already?
Thank you.

Re: Testing OM 7.0.0 #.....

[Alvaro]

## OM 7.0.0 #44

Server:  Ubuntu 18.04 - OM 7.0.0 #44

Clients:  Firefox 91-93 - Chrome 93 - Safari 14.1.2 - Yandex 21.6

 ...no issues found.


---




On Wed, 15 Sep 2021 09:54:44 +0200
Alvaro  wrote:

> 
> ## OM 7.0.0 #40
>  
> Server: Ubuntu 18.04 - OM 7.0.0 #40
>  
> Client: OSx 11.5.2 - Safari 14.1.2 - Firefox 91.0 - Chrome_Chromium 92.0.415 
> - 
> Yandex 21.6 
> 
>  ...no issues found.
> 
> 
> 
> --
> 
> 
> On Thu, 9 Sep 2021 12:52:03 +0200
> Alvaro  wrote:
> 
> > 
> > ## OM 7.0.0 #31
> > 
> > Server: Ubuntu 18.04 - OM 7.0.0 #31
> > 
> > Client: OSx 11.5.2 - Safari 14.1.2 - Firefox 91.0 - Chrome_Chromium 
> > 92.0.415 - Yandex
> > 
> >  ...no issues found.
> > 
> > 
> > -
> > 
> > 
> > On Thu, 26 Aug 2021 11:18:21 +0200
> > Alvaro  wrote:
> > 
> > > ## OM 7.0.0 #14
> > > 
> > > Server: Ubuntu 18.04 - OM 7.0.0 #14
> > > 
> > > Server: Ubuntu 21.04 - OM 7.0.0 #14
> > > 
> > > Client: OSx 11.5.2 - Safari 14.1.2 - Firefox 91.0 - Chrome_Chromium 
> > > 92.0.415 - Yandex
> > > 
> > > Client: Ubuntu 18.04 - Firefox 91.0 - Chrome 92.0.415
> > > 
> > >  ...no issues found.
> > > 
> > > 
> > > -
> > > 
> > > 
> > > 
> > > On Fri, 13 Aug 2021 11:47:50 +0200
> > > Alvaro  wrote:
> > > 
> > > > # OM 7.0.0 #13
> > > > 
> > > >  Server: Ubuntu 18.04 - OM 7.0.0 #13
> > > > 
> > > >  Client: OSx 11.5.2 - Safari 14.1.2 - Firefox 91.0 - Chrome_Chromium 
> > > > 92.0.415
> > > > 
> > > >  Client: Ubuntu 18.04 - Firefox 91.0 - Chrome 92.0.415
> > > > 
> > > >  ...no issues found.
> > > > 
> > > > 
> > > > ---
> > > > 
> > > > 
> > > > On Wed, 11 Aug 2021 12:54:47 +0200
> > > > Alvaro  wrote:
> > > > 
> > > > > # OM 7.0.0 #12
> > > > > 
> > > > >  Server: Ubuntu 18.04 - OM 7.0.0 #12
> > > > > 
> > > > >  Client: OSx 11.5.2 - Safari 14.1.2 - Firefox 90.0.2 - 
> > > > > Chrome_Chromium 92
> > > > > 
> > > > >  Client: Ubuntu 18.04 - Firefox 90.0.2 - Chrome 92
> > > > > 
> > > > >  ...no issues found.
> > > > > 
> > > > > 
> > > > > ..
> > > > > 
> > > > > 
> > > > > On Thu, 5 Aug 2021 17:56:14 +0200
> > > > > Alvaro  wrote:
> > > > > 
> > > > > > It would be good if a user does the test and not
> > > > > > finds errors, just expose it on
> > > > > > first send the mail to this thread,
> > > > > > so that the successive tests about the different
> > > > > > snapshots are next to each other and so you can
> > > > > > clearly see the differences between the snapshots.
> > > > > > 
> > > > > > Only if errors were found then, the second user
> > > > > > would expose it succinctly in this thread and open
> > > > > > a jira exposing the error in its entirety.
> > > > > > 
> > > > > > Thank you.
> > > > > > 
> > > > > > 
> > > > > > .
> > > > > > 
> > > > > > 
> > > > > > On Thu, 5 Aug 2021 14:45:57 +0300
> > > > > > Ali Alhaidary  wrote:
> > > > > > 
> > > > > > > # OM 7.0.0 #10
> > > > > > > 
> > > > > > > Server: Ubuntu 18.04 - OM 7.0.0 #10
> > > > > > > 
> > > > > > > Client: OSx 11.5.1 - Sefari 14.1.2 - Firefox 90.0.2
> > > > > > > 
> > > > > > > Client: Ubuntu 18.04 - Firefox 90.0.2
> > > > > > > 
> > > > > > > ...no errors found.
> > > > > > > 
> > > > > > > On 8/5/21 12:24 PM, Alvaro wrote:
> > > > > > > > Hello,
> > > > > > > >
> > > > > > > > This thread is only to show the results of testing
> > > > > > > > the successive snapshots of OM 7.0.0.
> > > > > > > >
> > > > > > > > 
> > > > > > > >
> > > > > > > > # OM 7.0.0 #10
> > > > > > > >
> > > > > > > > Server: Ubuntu 18.04 - OM 7.0.0 #10
> > > > > > > >
> > > > > > > > Client: OSx 11.5.1 - Sefari 14.1.2 - Firefox 90 - 
> > > > > > > > Chrome_Chromium 92
> > > > > > > >
> > > > > > > > Client: Ubuntu 18.04 - Firefox 90 - Chrome 92
> > > > > > > >
> > > > > > > > ...no errors found.
> > > > > > > >
> > > > > > > > 
> > > > > > > >
> > > > > > > >   
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > 
> > > > > > 
> > > > > > -- 
> > > > > > 
> > > > > 
> > > > > 
> > > > > -- 
> > > > > 
> > > > 
> > > > 
> > > > -- 
> > > > 
> > > 
> > > 
> > > -- 
> > > 
> > 
> > 
> > -- 
> > Alvaro
> 
> 
> -- 
> Alvaro


-- 
Alvaro

Re: [DISCUSS] Breaking JSON response body change in OpenMeetings Json/Rest API 7.0.0

[Daniel Baker]

Can you not employ an extra programmer?

On 22/09/2021 13:24, Maxim Solodovnik wrote:



On Wed, 22 Sept 2021 at 19:20, Ali Alhaidary 
mailto:ali.alhaid...@the5stars.org>> wrote:



On 9/22/21 3:14 PM, Maxim Solodovnik wrote:

I only can do manual testing here :(

What is manual testing?


I'm installing everything
setting up integration and do clicking :)))


IMO these changes (if we will be able to do them) worth to be done

what is IMO ?


In My Opinion :)


Why I raise some old design issues: we can do changes now and let
the API unchanged for another several years :)))

What is several years ;-)


Well I believe REST API was changed 2-3 times, so we are trying to 
keep it stable

v1/v2 etc. approach can also be applied
the problem here: I don't have enough time to maintain more than one 
version :((




On Wed, 22 Sept 2021 at 19:09, Ali Alhaidary
mailto:ali.alhaid...@the5stars.org>> wrote:

The issue here is that, It is a lot of work, and, a lot of
testing that follows. We are not a direct API users, however,
moodle plugin is. Along the road, things could break in such
change. So, if you see this change is the the way forward, I
am in with as usual a dedicated production server for
selected teaches/students as long as the old work (mainly
recordings) is not lost, and, only one environment is used
(as is now), i.e. moodle plugin can handle all the communication.

The issue is being discussed by only three people, how many
others are using these APIs ? How many apps are up and
running on them now ? looking at the moodle plugin downloads,
https://moodle.org/plugins/mod_openmeetings/stats
 there is
a peak during the past year, and I am sure the case is the
same with other LMS and custom built apps, keeping in mind
that OM can work exceptional good by itself.

Ali


On 9/22/21 2:16 PM, Maxim Solodovnik wrote:

These changes are only being discussed
Nothing is broken, yet :
we can @Deprecate these old methods and/or move it to some
prefixed URL
so API users will need to change base URL from
https://localhost:5443/openmeetings
 to
https://localhost:5443/openmeetings/v1


On Wed, 22 Sept 2021 at 13:14, seba.wag...@gmail.com
 mailto:seba.wag...@gmail.com>> wrote:

@Ali Alhaidary 
The other alternative to fix the issue AND make it
backwards compatible would be to have a /v2 version of
the API

So all endpoints would be duplicated to have version /v2
of the API (with maybe some other fixes)
and the current API stays the same. But would not
receive any improvements anymore/deprecated.

But that would be quite a bit of work. But yeah, that is
what people do when they want to avoid breaking changes.
Need to do versioning.

Thanks
Seb


Sebastian Wagner
Director Arrakeen Solutions, OM-Hosting.com
http://arrakeen-solutions.co.nz/

https://om-hosting.com  - Cloud
& Server Hosting for HTML5 Video-Conferencing OpenMeetings




On Wed, 22 Sept 2021 at 18:10, Ali Alhaidary
mailto:ali.alhaid...@the5stars.org>> wrote:

We are using OM in production with moodle front end,
we can not tolerate downtime neither with OM or its
plugin (that needs fixing, but living with), and to
tell you the truth, I do not see it as 'broken' from
that angle.

So my answer is B.

Ali

On 9/22/21 2:10 AM, seba.wag...@gmail.com
 wrote:

It is broken. The problem is the fix will be a
breaking change that will require 3rd party
integration code to be fixed. Not a big fix, but a
fix. Eg the Moodle Plugin requires some minor changes.

The workaround is to write some additional wrapper
code to make it backwards compatible. Which is also
a bit confusing.

I also don't understand quite if you answer is pro
or contra changing the response.

So is your statement:
A) Yes,

Re: [DISCUSS] Breaking JSON response body change in OpenMeetings Json/Rest API 7.0.0

[Ali Alhaidary]

On 9/22/21 3:24 PM, Maxim Solodovnik wrote:



On Wed, 22 Sept 2021 at 19:20, Ali Alhaidary 
mailto:ali.alhaid...@the5stars.org>> wrote:



On 9/22/21 3:14 PM, Maxim Solodovnik wrote:

I only can do manual testing here :(

What is manual testing?


I'm installing everything
setting up integration and do clicking :)))
A job very well done, thank you. We go through the testing with almost 
every build as well.



IMO these changes (if we will be able to do them) worth to be done

what is IMO ?


In My Opinion :)


Why I raise some old design issues: we can do changes now and let
the API unchanged for another several years :)))

What is several years ;-)


Well I believe REST API was changed 2-3 times, so we are trying to 
keep it stable

v1/v2 etc. approach can also be applied
the problem here: I don't have enough time to maintain more than one 
version :((
Yes, this is a blocker issue. I second you to look at old design issues 
and leave API for several years ;-)




On Wed, 22 Sept 2021 at 19:09, Ali Alhaidary
mailto:ali.alhaid...@the5stars.org>> wrote:

The issue here is that, It is a lot of work, and, a lot of
testing that follows. We are not a direct API users, however,
moodle plugin is. Along the road, things could break in such
change. So, if you see this change is the the way forward, I
am in with as usual a dedicated production server for
selected teaches/students as long as the old work (mainly
recordings) is not lost, and, only one environment is used
(as is now), i.e. moodle plugin can handle all the communication.

The issue is being discussed by only three people, how many
others are using these APIs ? How many apps are up and
running on them now ? looking at the moodle plugin downloads,
https://moodle.org/plugins/mod_openmeetings/stats
 there is
a peak during the past year, and I am sure the case is the
same with other LMS and custom built apps, keeping in mind
that OM can work exceptional good by itself.

Ali


On 9/22/21 2:16 PM, Maxim Solodovnik wrote:

These changes are only being discussed
Nothing is broken, yet :
we can @Deprecate these old methods and/or move it to some
prefixed URL
so API users will need to change base URL from
https://localhost:5443/openmeetings
 to
https://localhost:5443/openmeetings/v1


On Wed, 22 Sept 2021 at 13:14, seba.wag...@gmail.com
 mailto:seba.wag...@gmail.com>> wrote:

@Ali Alhaidary 
The other alternative to fix the issue AND make it
backwards compatible would be to have a /v2 version of
the API

So all endpoints would be duplicated to have version /v2
of the API (with maybe some other fixes)
and the current API stays the same. But would not
receive any improvements anymore/deprecated.

But that would be quite a bit of work. But yeah, that is
what people do when they want to avoid breaking changes.
Need to do versioning.

Thanks
Seb


Sebastian Wagner
Director Arrakeen Solutions, OM-Hosting.com
http://arrakeen-solutions.co.nz/

https://om-hosting.com  - Cloud
& Server Hosting for HTML5 Video-Conferencing OpenMeetings




On Wed, 22 Sept 2021 at 18:10, Ali Alhaidary
mailto:ali.alhaid...@the5stars.org>> wrote:

We are using OM in production with moodle front end,
we can not tolerate downtime neither with OM or its
plugin (that needs fixing, but living with), and to
tell you the truth, I do not see it as 'broken' from
that angle.

So my answer is B.

Ali

On 9/22/21 2:10 AM, seba.wag...@gmail.com
 wrote:

It is broken. The problem is the fix will be a
breaking change that will require 3rd party
integration code to be fixed. Not a big fix, but a
fix. Eg the Moodle Plugin requires some minor changes.

The workaround is to write some additional wrapper
code to make it backwards compatible. Which is also
a bit confusing.

Re: [DISCUSS] Breaking JSON response body change in OpenMeetings Json/Rest API 7.0.0

[Maxim Solodovnik]

On Wed, 22 Sept 2021 at 19:20, Ali Alhaidary 
wrote:

>
> On 9/22/21 3:14 PM, Maxim Solodovnik wrote:
>
> I only can do manual testing here :(
>
> What is manual testing?
>

I'm installing everything
setting up integration and do clicking :)))


> IMO these changes (if we will be able to do them) worth to be done
>
> what is IMO ?
>

In My Opinion :)

> Why I raise some old design issues: we can do changes now and let the API
> unchanged for another several years :)))
>
> What is several years ;-)
>

Well I believe REST API was changed 2-3 times, so we are trying to keep it
stable
v1/v2 etc. approach can also be applied
the problem here: I don't have enough time to maintain more than one
version :((


> On Wed, 22 Sept 2021 at 19:09, Ali Alhaidary 
> wrote:
>
>> The issue here is that, It is a lot of work, and, a lot of testing that
>> follows. We are not a direct API users, however, moodle plugin is. Along
>> the road, things could break in such change. So, if you see this change is
>> the the way forward, I am in with as usual a dedicated production server
>> for selected teaches/students as long as the old work (mainly recordings)
>> is not lost, and, only one environment is used (as is now), i.e. moodle
>> plugin can handle all the communication.
>>
>> The issue is being discussed by only three people, how many others are
>> using these APIs ? How many apps are up and running on them now ? looking
>> at the moodle plugin downloads,
>> https://moodle.org/plugins/mod_openmeetings/stats there is a peak during
>> the past year, and I am sure the case is the same with other LMS and custom
>> built apps, keeping in mind that OM can work exceptional good by itself.
>>
>> Ali
>>
>>
>> On 9/22/21 2:16 PM, Maxim Solodovnik wrote:
>>
>> These changes are only being discussed
>> Nothing is broken, yet :
>> we can @Deprecate these old methods and/or move it to some prefixed URL
>> so API users will need to change base URL from
>> https://localhost:5443/openmeetings to
>> https://localhost:5443/openmeetings/v1
>>
>> On Wed, 22 Sept 2021 at 13:14, seba.wag...@gmail.com <
>> seba.wag...@gmail.com> wrote:
>>
>>> @Ali Alhaidary 
>>> The other alternative to fix the issue AND make it backwards compatible
>>> would be to have a /v2 version of the API
>>>
>>> So all endpoints would be duplicated to have version /v2 of the API
>>> (with maybe some other fixes)
>>> and the current API stays the same. But would not receive any
>>> improvements anymore/deprecated.
>>>
>>> But that would be quite a bit of work. But yeah, that is what people do
>>> when they want to avoid breaking changes. Need to do versioning.
>>>
>>> Thanks
>>> Seb
>>>
>>>
>>> Sebastian Wagner
>>> Director Arrakeen Solutions, OM-Hosting.com
>>> http://arrakeen-solutions.co.nz/
>>> https://om-hosting.com - Cloud & Server Hosting for HTML5
>>> Video-Conferencing OpenMeetings
>>>
>>> 
>>> 
>>>
>>>
>>> On Wed, 22 Sept 2021 at 18:10, Ali Alhaidary <
>>> ali.alhaid...@the5stars.org> wrote:
>>>
 We are using OM in production with moodle front end, we can not
 tolerate downtime neither with OM or its plugin (that needs fixing, but
 living with), and to tell you the truth, I do not see it as 'broken' from
 that angle.

 So my answer is B.

 Ali
 On 9/22/21 2:10 AM, seba.wag...@gmail.com wrote:

 It is broken. The problem is the fix will be a breaking change that
 will require 3rd party integration code to be fixed. Not a big fix, but a
 fix. Eg the Moodle Plugin requires some minor changes.

 The workaround is to write some additional wrapper code to make it
 backwards compatible. Which is also a bit confusing.

 I also don't understand quite if you answer is pro or contra changing
 the response.

 So is your statement:
 A) Yes, lets fix it to align our JSON response with what the
 schema/method signature says. We don't like wrapper objects. And I am happy
 that people have to change their integration code to use newer versions of
 OpenMeetings.
 B) No, lets leave it like this for now and we do whatever other
 additional code we need to write to workaround so that our documentation
 and schema matches what the actual API responses look like

 If you could please clarify if you are A, B. Or if you don't mind
 either way/no strong opinion :)

 Thanks
 Seb


 Sebastian Wagner
 Director Arrakeen Solutions, OM-Hosting.com
 http://arrakeen-solutions.co.nz/
 https://om-hosting.com - Cloud & Server Hosting for HTML5
 Video-Conferencing OpenMeetings

 
 


 O

Re: [DISCUSS] Breaking JSON response body change in OpenMeetings Json/Rest API 7.0.0

[Ali Alhaidary]

On 9/22/21 3:14 PM, Maxim Solodovnik wrote:

I only can do manual testing here :(

What is manual testing?

IMO these changes (if we will be able to do them) worth to be done

what is IMO ?
Why I raise some old design issues: we can do changes now and let the 
API unchanged for another several years :)))

What is several years ;-)


On Wed, 22 Sept 2021 at 19:09, Ali Alhaidary 
mailto:ali.alhaid...@the5stars.org>> wrote:


The issue here is that, It is a lot of work, and, a lot of testing
that follows. We are not a direct API users, however, moodle
plugin is. Along the road, things could break in such change. So,
if you see this change is the the way forward, I am in with as
usual a dedicated production server for selected teaches/students
as long as the old work (mainly recordings) is not lost, and, only
one environment is used (as is now), i.e. moodle plugin can handle
all the communication.

The issue is being discussed by only three people, how many others
are using these APIs ? How many apps are up and running on them
now ? looking at the moodle plugin downloads,
https://moodle.org/plugins/mod_openmeetings/stats
 there is a
peak during the past year, and I am sure the case is the same with
other LMS and custom built apps, keeping in mind that OM can work
exceptional good by itself.

Ali


On 9/22/21 2:16 PM, Maxim Solodovnik wrote:

These changes are only being discussed
Nothing is broken, yet :
we can @Deprecate these old methods and/or move it to some
prefixed URL
so API users will need to change base URL from
https://localhost:5443/openmeetings
 to
https://localhost:5443/openmeetings/v1


On Wed, 22 Sept 2021 at 13:14, seba.wag...@gmail.com
 mailto:seba.wag...@gmail.com>> wrote:

@Ali Alhaidary 
The other alternative to fix the issue AND make it backwards
compatible would be to have a /v2 version of the API

So all endpoints would be duplicated to have version /v2 of
the API (with maybe some other fixes)
and the current API stays the same. But would not receive any
improvements anymore/deprecated.

But that would be quite a bit of work. But yeah, that is what
people do when they want to avoid breaking changes. Need to
do versioning.

Thanks
Seb


Sebastian Wagner
Director Arrakeen Solutions, OM-Hosting.com
http://arrakeen-solutions.co.nz/

https://om-hosting.com  - Cloud &
Server Hosting for HTML5 Video-Conferencing OpenMeetings




On Wed, 22 Sept 2021 at 18:10, Ali Alhaidary
mailto:ali.alhaid...@the5stars.org>> wrote:

We are using OM in production with moodle front end, we
can not tolerate downtime neither with OM or its plugin
(that needs fixing, but living with), and to tell you the
truth, I do not see it as 'broken' from that angle.

So my answer is B.

Ali

On 9/22/21 2:10 AM, seba.wag...@gmail.com
 wrote:

It is broken. The problem is the fix will be a breaking
change that will require 3rd party integration code to
be fixed. Not a big fix, but a fix. Eg the Moodle Plugin
requires some minor changes.

The workaround is to write some additional wrapper code
to make it backwards compatible. Which is also a bit
confusing.

I also don't understand quite if you answer is pro or
contra changing the response.

So is your statement:
A) Yes, lets fix it to align our JSON response with what
the schema/method signature says. We don't like wrapper
objects. And I am happy that people have to change their
integration code to use newer versions of OpenMeetings.
B) No, lets leave it like this for now and we do
whatever other additional code we need to write to
workaround so that our documentation and schema matches
what the actual API responses look like

If you could please clarify if you are A, B. Or if you
don't mind either way/no strong opinion :)

Thanks
Seb


Sebastian Wagner
Director Arrakeen Solutions, OM-Hosting.com
http://arrakeen-solutions.co.nz/

Re: [DISCUSS] Breaking JSON response body change in OpenMeetings Json/Rest API 7.0.0

[Maxim Solodovnik]

I only can do manual testing here :(
IMO these changes (if we will be able to do them) worth to be done
Why I raise some old design issues: we can do changes now and let the API
unchanged for another several years :)))

On Wed, 22 Sept 2021 at 19:09, Ali Alhaidary 
wrote:

> The issue here is that, It is a lot of work, and, a lot of testing that
> follows. We are not a direct API users, however, moodle plugin is. Along
> the road, things could break in such change. So, if you see this change is
> the the way forward, I am in with as usual a dedicated production server
> for selected teaches/students as long as the old work (mainly recordings)
> is not lost, and, only one environment is used (as is now), i.e. moodle
> plugin can handle all the communication.
>
> The issue is being discussed by only three people, how many others are
> using these APIs ? How many apps are up and running on them now ? looking
> at the moodle plugin downloads,
> https://moodle.org/plugins/mod_openmeetings/stats there is a peak during
> the past year, and I am sure the case is the same with other LMS and custom
> built apps, keeping in mind that OM can work exceptional good by itself.
>
> Ali
>
>
> On 9/22/21 2:16 PM, Maxim Solodovnik wrote:
>
> These changes are only being discussed
> Nothing is broken, yet :
> we can @Deprecate these old methods and/or move it to some prefixed URL
> so API users will need to change base URL from
> https://localhost:5443/openmeetings to
> https://localhost:5443/openmeetings/v1
>
> On Wed, 22 Sept 2021 at 13:14, seba.wag...@gmail.com <
> seba.wag...@gmail.com> wrote:
>
>> @Ali Alhaidary 
>> The other alternative to fix the issue AND make it backwards compatible
>> would be to have a /v2 version of the API
>>
>> So all endpoints would be duplicated to have version /v2 of the API (with
>> maybe some other fixes)
>> and the current API stays the same. But would not receive any
>> improvements anymore/deprecated.
>>
>> But that would be quite a bit of work. But yeah, that is what people do
>> when they want to avoid breaking changes. Need to do versioning.
>>
>> Thanks
>> Seb
>>
>>
>> Sebastian Wagner
>> Director Arrakeen Solutions, OM-Hosting.com
>> http://arrakeen-solutions.co.nz/
>> https://om-hosting.com - Cloud & Server Hosting for HTML5
>> Video-Conferencing OpenMeetings
>>
>> 
>> 
>>
>>
>> On Wed, 22 Sept 2021 at 18:10, Ali Alhaidary 
>> wrote:
>>
>>> We are using OM in production with moodle front end, we can not tolerate
>>> downtime neither with OM or its plugin (that needs fixing, but living
>>> with), and to tell you the truth, I do not see it as 'broken' from that
>>> angle.
>>>
>>> So my answer is B.
>>>
>>> Ali
>>> On 9/22/21 2:10 AM, seba.wag...@gmail.com wrote:
>>>
>>> It is broken. The problem is the fix will be a breaking change that will
>>> require 3rd party integration code to be fixed. Not a big fix, but a fix.
>>> Eg the Moodle Plugin requires some minor changes.
>>>
>>> The workaround is to write some additional wrapper code to make it
>>> backwards compatible. Which is also a bit confusing.
>>>
>>> I also don't understand quite if you answer is pro or contra changing
>>> the response.
>>>
>>> So is your statement:
>>> A) Yes, lets fix it to align our JSON response with what the
>>> schema/method signature says. We don't like wrapper objects. And I am happy
>>> that people have to change their integration code to use newer versions of
>>> OpenMeetings.
>>> B) No, lets leave it like this for now and we do whatever other
>>> additional code we need to write to workaround so that our documentation
>>> and schema matches what the actual API responses look like
>>>
>>> If you could please clarify if you are A, B. Or if you don't mind either
>>> way/no strong opinion :)
>>>
>>> Thanks
>>> Seb
>>>
>>>
>>> Sebastian Wagner
>>> Director Arrakeen Solutions, OM-Hosting.com
>>> http://arrakeen-solutions.co.nz/
>>> https://om-hosting.com - Cloud & Server Hosting for HTML5
>>> Video-Conferencing OpenMeetings
>>>
>>> 
>>> 
>>>
>>>
>>> On Wed, 22 Sept 2021 at 10:59, Ali Alhaidary <
>>> ali.alhaid...@the5stars.org> wrote:
>>>
 Hi,

 We have an old saying 'If it is not broken, do not fix it' ;-)

 Ali
 On 9/22/21 12:46 AM, seba.wag...@gmail.com wrote:

 Hi,

 as discussed in the comments section in
 https://github.com/apache/openmeetings/commit/4daf7c1f53738cd786dc976114cc5278b4f05f4f#comments


 we would like to propose a breaking change for the OpenMeetings
 Json/Rest API in v7.0.0

 Problem: JSON response wrapping
 Currently CXF-RS is configured to wrap the JSON response into another
>

Re: [DISCUSS] Breaking JSON response body change in OpenMeetings Json/Rest API 7.0.0

[Ali Alhaidary]

The issue here is that, It is a lot of work, and, a lot of testing that 
follows. We are not a direct API users, however, moodle plugin is. Along 
the road, things could break in such change. So, if you see this change 
is the the way forward, I am in with as usual a dedicated production 
server for selected teaches/students as long as the old work (mainly 
recordings) is not lost, and, only one environment is used (as is now), 
i.e. moodle plugin can handle all the communication.


The issue is being discussed by only three people, how many others are 
using these APIs ? How many apps are up and running on them now ? 
looking at the moodle plugin downloads, 
https://moodle.org/plugins/mod_openmeetings/stats there is a peak during 
the past year, and I am sure the case is the same with other LMS and 
custom built apps, keeping in mind that OM can work exceptional good by 
itself.


Ali


On 9/22/21 2:16 PM, Maxim Solodovnik wrote:

These changes are only being discussed
Nothing is broken, yet :
we can @Deprecate these old methods and/or move it to some prefixed URL
so API users will need to change base URL from 
https://localhost:5443/openmeetings 
 to 
https://localhost:5443/openmeetings/v1 



On Wed, 22 Sept 2021 at 13:14, seba.wag...@gmail.com 
 > wrote:


@Ali Alhaidary 
The other alternative to fix the issue AND make it backwards
compatible would be to have a /v2 version of the API

So all endpoints would be duplicated to have version /v2 of the
API (with maybe some other fixes)
and the current API stays the same. But would not receive any
improvements anymore/deprecated.

But that would be quite a bit of work. But yeah, that is what
people do when they want to avoid breaking changes. Need to do
versioning.

Thanks
Seb


Sebastian Wagner
Director Arrakeen Solutions, OM-Hosting.com
http://arrakeen-solutions.co.nz/ 
https://om-hosting.com  - Cloud & Server
Hosting for HTML5 Video-Conferencing OpenMeetings




On Wed, 22 Sept 2021 at 18:10, Ali Alhaidary
mailto:ali.alhaid...@the5stars.org>>
wrote:

We are using OM in production with moodle front end, we can
not tolerate downtime neither with OM or its plugin (that
needs fixing, but living with), and to tell you the truth, I
do not see it as 'broken' from that angle.

So my answer is B.

Ali

On 9/22/21 2:10 AM, seba.wag...@gmail.com
 wrote:

It is broken. The problem is the fix will be a breaking
change that will require 3rd party integration code to be
fixed. Not a big fix, but a fix. Eg the Moodle Plugin
requires some minor changes.

The workaround is to write some additional wrapper code to
make it backwards compatible. Which is also a bit confusing.

I also don't understand quite if you answer is pro or contra
changing the response.

So is your statement:
A) Yes, lets fix it to align our JSON response with what the
schema/method signature says. We don't like wrapper objects.
And I am happy that people have to change their integration
code to use newer versions of OpenMeetings.
B) No, lets leave it like this for now and we do whatever
other additional code we need to write to workaround so that
our documentation and schema matches what the actual API
responses look like

If you could please clarify if you are A, B. Or if you don't
mind either way/no strong opinion :)

Thanks
Seb


Sebastian Wagner
Director Arrakeen Solutions, OM-Hosting.com
http://arrakeen-solutions.co.nz/

https://om-hosting.com  - Cloud &
Server Hosting for HTML5 Video-Conferencing OpenMeetings




On Wed, 22 Sept 2021 at 10:59, Ali Alhaidary
mailto:ali.alhaid...@the5stars.org>> wrote:

Hi,

We have an old saying 'If it is not broken, do not fix
it' ;-)

Ali

On 9/22/21 12:46 AM, seba.wag...@gmail.com
 wrote:

Hi,

as discussed in the comments section in

https://github.com/apache/openmeetings/commit/4daf7c1f53738cd786d

Re: [DISCUSS] Breaking JSON response body change in OpenMeetings Json/Rest API 7.0.0

[Maxim Solodovnik]

These changes are only being discussed
Nothing is broken, yet :
we can @Deprecate these old methods and/or move it to some prefixed URL
so API users will need to change base URL from
https://localhost:5443/openmeetings to
https://localhost:5443/openmeetings/v1

On Wed, 22 Sept 2021 at 13:14, seba.wag...@gmail.com 
wrote:

> @Ali Alhaidary 
> The other alternative to fix the issue AND make it backwards compatible
> would be to have a /v2 version of the API
>
> So all endpoints would be duplicated to have version /v2 of the API (with
> maybe some other fixes)
> and the current API stays the same. But would not receive any improvements
> anymore/deprecated.
>
> But that would be quite a bit of work. But yeah, that is what people do
> when they want to avoid breaking changes. Need to do versioning.
>
> Thanks
> Seb
>
>
> Sebastian Wagner
> Director Arrakeen Solutions, OM-Hosting.com
> http://arrakeen-solutions.co.nz/
> https://om-hosting.com - Cloud & Server Hosting for HTML5
> Video-Conferencing OpenMeetings
>
> 
> 
>
>
> On Wed, 22 Sept 2021 at 18:10, Ali Alhaidary 
> wrote:
>
>> We are using OM in production with moodle front end, we can not tolerate
>> downtime neither with OM or its plugin (that needs fixing, but living
>> with), and to tell you the truth, I do not see it as 'broken' from that
>> angle.
>>
>> So my answer is B.
>>
>> Ali
>> On 9/22/21 2:10 AM, seba.wag...@gmail.com wrote:
>>
>> It is broken. The problem is the fix will be a breaking change that will
>> require 3rd party integration code to be fixed. Not a big fix, but a fix.
>> Eg the Moodle Plugin requires some minor changes.
>>
>> The workaround is to write some additional wrapper code to make it
>> backwards compatible. Which is also a bit confusing.
>>
>> I also don't understand quite if you answer is pro or contra changing the
>> response.
>>
>> So is your statement:
>> A) Yes, lets fix it to align our JSON response with what the
>> schema/method signature says. We don't like wrapper objects. And I am happy
>> that people have to change their integration code to use newer versions of
>> OpenMeetings.
>> B) No, lets leave it like this for now and we do whatever other
>> additional code we need to write to workaround so that our documentation
>> and schema matches what the actual API responses look like
>>
>> If you could please clarify if you are A, B. Or if you don't mind either
>> way/no strong opinion :)
>>
>> Thanks
>> Seb
>>
>>
>> Sebastian Wagner
>> Director Arrakeen Solutions, OM-Hosting.com
>> http://arrakeen-solutions.co.nz/
>> https://om-hosting.com - Cloud & Server Hosting for HTML5
>> Video-Conferencing OpenMeetings
>>
>> 
>> 
>>
>>
>> On Wed, 22 Sept 2021 at 10:59, Ali Alhaidary 
>> wrote:
>>
>>> Hi,
>>>
>>> We have an old saying 'If it is not broken, do not fix it' ;-)
>>>
>>> Ali
>>> On 9/22/21 12:46 AM, seba.wag...@gmail.com wrote:
>>>
>>> Hi,
>>>
>>> as discussed in the comments section in
>>> https://github.com/apache/openmeetings/commit/4daf7c1f53738cd786dc976114cc5278b4f05f4f#comments
>>>
>>>
>>> we would like to propose a breaking change for the OpenMeetings
>>> Json/Rest API in v7.0.0
>>>
>>> Problem: JSON response wrapping
>>> Currently CXF-RS is configured to wrap the JSON response into another
>>> object.
>>>
>>> Example: Method signature: public List range(...) { ...
>>> } (Example taken from
>>> https://github.com/apache/openmeetings/blob/master/openmeetings-webservice/src/main/java/org/apache/openmeetings/webservice/CalendarWebService.java#L111
>>> )
>>>
>>> OLD/CURRENT JSON Response:
>>> {
>>>   "appointmentDTO":
>>> [
>>>   {
>>>  itemXYZ: 123, ...
>>>}
>>> ]
>>> }
>>>
>>>
>>> Proposed NEW/UPDATED JSON Response:
>>> // no wrapping object around it, just return list
>>> [
>>>   {
>>>  itemXYZ: 123, ...
>>>}
>>> ]
>>>
>>> Reasoning: The wrapping "{  "appointmentDTO": ... }" should be dropped
>>> from the json response body. "appointmentDTO" is generated but it is not in
>>> any schema definition or method signature. Cause there is nothing in the
>>> method signature that would tell anybody where " "appointmentDTO": [" is
>>> coming from. Other than by testing the API call and finding out by try and
>>> error.
>>>
>>> CXF-RS allows configuring our Web Service to NOT generate that wrapping
>>> element. And turn this behaviour off and just generate the list.
>>> See "dropRootName" in the CXF docs at:
>>>
>>> https://cxf.apache.org/docs/jax-rs-data-bindings.html#JAXRSDataBindings-WrappingandUnwrappingJSONsequences
>>>
>>> *This affects all methods returning a JSON response body (which is
>>> pretty much every API Method)*
>>>
>>> Please reply to this email if yo

Re: [DISCUSS] Breaking JSON response body change in OpenMeetings Json/Rest API 7.0.0

[Maxim Solodovnik]

On Wed, 22 Sept 2021 at 13:11, seba.wag...@gmail.com 
wrote:

> @Maxim Solodovnik 
> The strange thing about those POST requests is that its a @FormParam. And
> not just a simple request post body.
>

Well
@FormParam was used due to this was the option I was able to find :)))
My goal was to be able to get *multiple* parameters which are POJOs :)))
Maybe this is possible with @BeanParam instead?
I would investigate
This might make our API much better :)


>
> Those methods are POST Methods. So by definition the payload should be
> sent in the POST request body. Makes sense? :)
>
> However a POST Body, only has 1 Body. You can NOT put 2 bodies into 1
> post. This also makes send in terms of RESTFul APIs: POST endpoint creates
> 1 object. Not 2 objects.
>
> But some of our methods have 2 FormParams, for example:
> UserService::getRoomHash(@QueryParam("sid") String SID,
> @FormParam("user") ExternalUserDTO user,
> @FormParam("options") RoomOptionsDTO options) { ... }
>
> 2 form params: ExternalUserDTO user + RoomOptionsDTO options
> => THis won't be able to just put into 1 post body. You would need to then
> again create a "parent/wrapper" object so that its a 1 object, and you can
> have it in 1 post body.
>
> FormParams are still sent in the Post Body. But its different sections.
> They are sent as "multipart/form-data" which is what we currently use. But
> it sets some boundaries so it can decipher the parameters separated. Which
> is actually quite complicated. But that's what we currently do.
>
> The other alternative is to completely specify all params into a long list
> of parameters and eg use "application/x-www-form-urlencoded" but that would
> mean:
> A) You need to do URL encode on the variable before putting it into the
> payload on the client side
> B) On the server side do a URL decode on the variable
> => Also pretty ugly
>
> So I yeah, I think it would be worth resolving this. But ideally we should
> follow the RESTFul guidelines, which say "POST body". But that would quite
> a change to get it done.
> So yeah I also think this would be nice to resolve but unfortunately it
> doesn't seem there is a very simple or elegant way from where we are now ?
>
> Thanks
> Seb
>
> Sebastian Wagner
> Director Arrakeen Solutions, OM-Hosting.com
> http://arrakeen-solutions.co.nz/
> https://om-hosting.com - Cloud & Server Hosting for HTML5
> Video-Conferencing OpenMeetings
>
> 
> 
>
>
> On Wed, 22 Sept 2021 at 17:52, Maxim Solodovnik 
> wrote:
>
>>
>>
>> On Wed, 22 Sept 2021 at 12:37, seba.wag...@gmail.com <
>> seba.wag...@gmail.com> wrote:
>>
>>> I'm +1 for the change :)
>>> => OK
>>>
>>> right now we have `JSON.stringify` [1] in some places, and NOT in some
>>> others. I would completely get rid of it :(
>>> => You mean from the request parameter or response parameters ?
>>>
>>
>> it's in request
>> this was the only way I found to pass more than one JSON object as a
>> parameter ... :(
>> (ugly but works)
>> as far as I remember is was most unclear thing in our API
>>
>> Maybe you can point to some others :)
>>
>>
>>>
>>> Thanks
>>> Seb
>>>
>>>
>>> Sebastian Wagner
>>> Director Arrakeen Solutions, OM-Hosting.com
>>> http://arrakeen-solutions.co.nz/
>>> https://om-hosting.com - Cloud & Server Hosting for HTML5
>>> Video-Conferencing OpenMeetings
>>>
>>> 
>>> 
>>>
>>>
>>> On Wed, 22 Sept 2021 at 17:19, Maxim Solodovnik 
>>> wrote:
>>>
 I'm +1 for the change :)

 And I propose to check the current REST API to be clearer
 for ex. right now we have `JSON.stringify` [1] in some places, and NOT
 in some others
 I would completely get rid of it :(

 this particular change is small and will affect 1-2 lines of code in
 Moodle plugin :)

 [1] https://openmeetings.apache.org/RestAPISample.html

 On Wed, 22 Sept 2021 at 06:11, seba.wag...@gmail.com <
 seba.wag...@gmail.com> wrote:

> It is broken. The problem is the fix will be a breaking change that
> will require 3rd party integration code to be fixed. Not a big fix, but a
> fix. Eg the Moodle Plugin requires some minor changes.
>
> The workaround is to write some additional wrapper code to make it
> backwards compatible. Which is also a bit confusing.
>
> I also don't understand quite if you answer is pro or contra changing
> the response.
>
> So is your statement:
> A) Yes, lets fix it to align our JSON response with what the
> schema/method signature says. We don't like wrapper objects. And I am 
> happy
> that people have to change their integration code to use newer versions of
> OpenMeetings.
> B)