On Fri, Jan 18, 2019 at 12:52 PM Nick Couchman <vn...@apache.org> wrote:
> On Fri, Jan 18, 2019 at 2:37 PM Mike Jumper <mjum...@apache.org> wrote: > > > On Thu, Jan 17, 2019, 13:02 Nick Couchman <vn...@apache.org wrote: > > > > > On Fri, Jan 11, 2019 at 9:56 PM Mike Jumper <mjum...@apache.org> > wrote: > > > > > > > > > > > Another option might be to provide some sort of API compatibility > layer > > > > within the webapp, allowing the extensions of prior releases to > > continue > > > to > > > > function. If compatibility doesn't break as a result of API changes, > > > > there's no need for a full major version bump, and downstream > migration > > > for > > > > future releases is much easier. > > > > > > > > > > > I'm open to this, as well. How much effort do we think would be > involved > > > in introducing something like this? > > > > > > > A compat layer would be pretty tricky. > > > > If we can somehow modify the API changes such that things are inherently > > compatible, then fairly easy. Maybe something can be done with default > > methods now that we're Java 8+? > > > > So, for a change like this (to the Connectable interface): > > https://github.com/apache/guacamole-client/commit/dfd43327618bd625bac7ce4fd35f9ccfe729ec6e#diff-1d2cb5f9d0009ea051d8a6211b20aaea > > ....something like this: > > https://github.com/necouchman/guacamole-client/commit/d53a6c3be576526ace6acf0432cab2480785a0ae > > ?? > > Something similar to that, yes. We would need default implementations for both old and new versions of connect(): https://github.com/mike-jumper/guacamole-client/commit/4a1527b1d4311bbf9d76468141dc68d02a90efa4 We would still run into trouble with the SimpleConnection class for any downstream uses which override the old connect(). Those overrides would suddenly cease to have any effect. Further, if such a downstream use also uses SimpleAuthenticationProvider, they might expect the provided GuacamoleConfiguration to already have tokens applied (the old behavior) rather than dynamically applied upon connect() (the new behavior). Maybe it's not possible without a compatibility layer... > On another note, I have started looking at the changes required to support > FreeRDP 2.0. I know you asked for help on this a while back, with no > takers. It might take me 10x as long as someone else to figure it out, but > it's clear from some recent traffic on the list that it's going to be > pretty important that we support FreeRDP 2.0 going forward. So, time to > tackle it :-). Unfortunately just an hour or so into it and I already want > to run my head through a brick wall. Speaking of API compatibility, these > changes are not insignificant... Yeah, that's pretty typical in my experience of FreeRDP API changes. I did some work recently trying to abstract away the VNC support from the underlying library, and I think we can do the same with the RDP - allowing FreeRDP 1.x and 2.x to be alternative backends fo the same support. It's not the easiest thing ever, but it wasn't too horrible. I'll give it a shot. - Mike
