[GitHub] WojoInc commented on issue #320: GUACAMOLE-626: Add support for Docker secrets to startup.sh

[GitBox]

WojoInc commented on issue #320: GUACAMOLE-626: Add support for Docker secrets 
to startup.sh
URL: https://github.com/apache/guacamole-client/pull/320#issuecomment-455752596
 
 
   @necouchman Updated PR title and commit messages. Fixed the README issues as 
well and cleaned up the formatting. Please let me know if anything else looks 
off!


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] mike-jumper commented on issue #359: Guacamole 617: Extract Permission Management from JDBC Authentication Module

[GitBox]

mike-jumper commented on issue #359: Guacamole 617: Extract Permission 
Management from JDBC Authentication Module
URL: https://github.com/apache/guacamole-client/pull/359#issuecomment-455740406
 
 
   Please also make sure you do not include merge commits in the set of commits 
for a pull request (if changes need to be rebased, please rebase them, but no 
merges), and update your commit messages to follow the [contribution 
guidelines](https://github.com/apache/guacamole-client/blob/master/CONTRIBUTING):
   
   >
   > ... Commits should be made in logical units and must reference the JIRA 
issue number:
   >
   > $ git commit -m "GUACAMOLE-123: High-level message describing the 
changes."
   >
   
   The git history and the contents of other PRs should serve as a good example 
for the above.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

Re: Guacamole extensión MongoDB

[Daniel Quirant Rico]

Hello,

After a lot of work, I can finally share with you my contribution to this
project.
You already have available for your review the extension that supports
MongoDB through Morphia.
In addition to a new library in which a large part of the shared code is
available for the authentication module. This part has been restructured
through genericity to be able to reuse it in future implementations if
necessary.

Regards!

El sáb., 12 ene. 2019 a las 18:47, Daniel Quirant Rico (<
daniel.quirant.r...@gmail.com>) escribió:

> Hello,
>
> I have advanced a lot in the development of the common authentication
> extension for jdbc and mongo. At this moment I have a stable enough version
> to share it with you and together find all possible faults that remain to
> be resolved.
> I am aware that there are several errors in the application, but I have a
> deployment booted with MySQL and MongoDB. The two deployments are
> accessible and you can navigate well through the different options, I ask
> for your help to find the errors that may arise when making the different
> possible cases in the application since I do not know the whole functional
> part.
> If you agree I prepare the pull request with my development, this includes
> two new libraries, the implementation of the guacamole database with
> morphia using mongodb and the shared library with all the common code
> between morphia and jdbc for authentication. In addition to the adaptation
> of the existing libraries of jdbc to use the new common dependency.
>
> The name of the classes that I have used may not be suitable, since to
> guide me I chose to name all the classes and interfaces, which had to be
> reimplemented in the specific parts of jdbc and morphia, as an abstract in
> the final part of the name . This will be refactored at the end of the
> development with a more coherent nomenclature.
>
> I hope that the development is at the level you are looking for.
>
> I feel if the language used is not adequate, I do not speak the language
> correctly.
>
> A greeting.
>
> El mar., 8 ene. 2019 a las 17:32, Daniel Quirant Rico (<
> daniel.quirant.r...@gmail.com>) escribió:
>
>> Hello,
>>
>> Thanks for your interest.
>> I have finished the integration and I am solving small errors. During the 
>> next week I will try to upload the code, depending on the time I have free 
>> to finish reviewing the code, and you can help prove it.
>>
>> PS: I've noticed that in a previous email I mentioned that I was working on 
>> version 0.9.4, I meant 0.9.14.
>>
>> Greetings.
>>
>>
>> El dom., 6 ene. 2019 15:26, fou fe  escribió:
>>
>>> Hi
>>> I m interesting to test your extension.
>>> If you need help i m here.
>>>
>>> Fouad
>>>
>>> Télécharger Outlook pour Android 
>>>
>>> --
>>> *From:* Daniel Quirant Rico 
>>> *Sent:* Thursday, January 3, 2019 2:16:17 AM
>>> *To:* dev@guacamole.apache.org
>>> *Subject:* Re: Guacamole extensión MongoDB
>>>
>>> Hello,
>>>
>>> I still work hard on the common base extension, a week ago I finished the
>>> development but there were many changes since I initially fork.
>>> I have updated my fork and am adapting the whole new part of the user
>>> groups to be able to run all the databases. By mistake when updating my
>>> fork I created a pull request, I feel the confusion.
>>> The adaptation completed for version 0.9.4 looks very good, I will
>>> continue
>>> working hard until I complete version 1.0.0.
>>> If you wish, I can upload version 0.9.4 so you can take a look.
>>>
>>> Greetings and happy new year.
>>>
>>> El lun., 17 dic. 2018 a las 21:31, Daniel Quirant Rico (<
>>> daniel.quirant.r...@gmail.com>) escribió:
>>>
>>> > I'm going to review the code a bit more to clean it, for now I have the
>>> > morphia part running, I'll check that everything works in the sql part
>>> and
>>> > I'll do a pull request so you can check it.
>>> >
>>> > El vie., 14 dic. 2018 a las 12:55, Nick Couchman ()
>>> > escribió:
>>> >
>>> >> >
>>> >> > I think I have explained it more or less well, it is possible that
>>> my
>>> >> > expression in the language is not the most appropriate since I do
>>> not
>>> >> speak
>>> >> > English well.
>>> >> >
>>> >> > I hope you respond with ideas and proposals, as well as your
>>> opinion on
>>> >> > what I am trying to solve.
>>> >> > If you need to see the code, I can share it without problem, even
>>> if it
>>> >> is
>>> >> > not completely finished.
>>> >> >
>>> >>
>>> >> I think you did a great job of explaining it, but I do better seeing
>>> >> actual
>>> >> code, so if you wouldn't mind sharing examples of what you have, that
>>> >> would
>>> >> probably be best, at least for me.
>>> >>
>>> >> -Nick
>>> >>
>>> >
>>>
>>

[GitHub] daniquir opened a new pull request #359: Guacamole 617: Extract Permission Management from JDBC Authentication Module

[GitBox]

daniquir opened a new pull request #359: Guacamole 617: Extract Permission 
Management from JDBC Authentication Module
URL: https://github.com/apache/guacamole-client/pull/359
 
 
   New external library with the common code of the authentication module.
   Adaptation of the JDBC extensions to use the new library.
   Morphia extension with MongoDB using the new library.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

Re: [DISCUSS] Beyond 1.0.0

[Nick Couchman]

On Fri, Jan 18, 2019 at 2:37 PM Mike Jumper  wrote:

> On Thu, Jan 17, 2019, 13:02 Nick Couchman 
> > On Fri, Jan 11, 2019 at 9:56 PM Mike Jumper  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

??

I assume if we wanted to do this for 2.0.0 (or 1.1.0, etc.) we'd need to go
back and look at everything that's been changed in guacamole-ext and
basically add
these default methods for any methods where we changed the parameters being
passed in?  Is it just for Interfaces, or would it also be Abstract Classes
within the guacamole-ext component?

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...

-Nick

Re: [DISCUSS] Beyond 1.0.0

[Mike Jumper]

On Thu, Jan 17, 2019, 13:02 Nick Couchman  On Fri, Jan 11, 2019 at 9:56 PM Mike Jumper  wrote:
>
> > On Fri, Jan 11, 2019 at 6:39 AM Nick Couchman  wrote:
> >
> > > On Fri, Jan 11, 2019 at 8:11 AM carl harris 
> > wrote:
> > > ...
> > > >
> > > > Many products have skirted this question by dropping the semantic
> > > > versioning in favor of some sort of version scheme based on a
> > time-boxed
> > > > release cycle. Would something like that be more appropriate here?
> What
> > > > would that mean with respect to versioning for the API that Guacamole
> > > > exposes for extensions and such?
> > > >
> > >
> > > I'm not opposed to such a versioning scheme.  My only question would be
> > how
> > > to deal with the API-level changes that you mentioned before, and that
> > > we've currently identified for the "major release" changes?  Is there a
> > way
> > > that these sort of time-boxed releases handle that in the versioning?
> > >
> >
> > 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+?


> I guess, whatever methodology we choose for this going forward, I'm
> interested in maintaining the momentum of the really cool 1.0.0 release we
> just put out - I think we'll be able to increase community involvement and
> interest by maintaining and more frequent release cycle, which I believe
> the new version numbering is supposed to facilitate.  It'd be nice to
> identify a sustainable way to develop and version going forward, and turn
> around another release (2.0.0, 1.0.1, 1.0-201902, etc.) quickly.
>

+1


> Sorry if I'm coming across as push, but I'm very interested in carrying the
> energy and momentum forward :-).
>

I definitely agree. There's been a remarkable uptick in community
involvement following 1.0.0 which we should work to encourage.

- Mike

[GitHub] jolentes commented on issue #358: [WIP] GUACAMOLE-706: added variable to define link name of RADIUS extension

[GitBox]

jolentes commented on issue #358: [WIP] GUACAMOLE-706: added variable to define 
link name of RADIUS extension
URL: https://github.com/apache/guacamole-client/pull/358#issuecomment-455470330
 
 
   Yes, came to my mind also.
   With the current implementation so far you don't need to specify the file 
name on the `ln` command. As soon as you start to specify part of the name for 
`ln` you need to state the full name of the link.
   Therefore you need to determine the precise name of the JAR file.
   If you just configure the target link name you don't need to know the source 
name exactly in the same way the current implementation doesn't know. Keep it 
simple.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services