Mike has already replied, addressing the way you went about expressing your frustration; I'd like to address several of the claims you've made about this project.
On Sun, Mar 25, 2018 at 7:56 PM, Vlad CopyLove <[email protected]> wrote: > From http://apache-guacamole-general-user-mailing-list. > 2363388.n4.nabble.com/Extension-showing-VM-status-td2955.html > > After looking deeper at extensions and looking at this mess of a > discussion, it seems that the definition of Extension you guys at > guacamole dev are using is wrong. What I see is like making new > software all together - not an extension. > If you made some path one application can interact with another - it > is not extension - it is API at best if not BS > Actually, it is an extension, in the context of the Guacamole project. Many projects define extensions in different ways, and many of them require writing code and interfacing in a standardized way with the software being extended. NextCloud/OwnCloud, Cacti, and MediaWiki come to mind as examples of software that provide a standard way to interact with the software and require you to some amount of code to extend the software. And, all three of those define "extension" in a different way - there's a different interface and a different required number of things you have to do to extend their product. It isn't a single file (as you state below), where you add some configuration items - that's configuring, not extending. Guacamole defines extension in its own, well-documented way. > > Close to proper understanding - extension should use internal > framework of the software with ability to make changes stay when > software framework changes. it is crazy to ask people make everything > on the side - css, html, sql and everything else. > And even more silly to expect someone to use this so called extension > way of things you present with such scope. No wonders there are no > extensions. > I agree with your first statement here, and this is definitely true of Guacamole extensions - extensions in Guacamole use a well-defined internal framework to interact with the rest of the code - namely the guacamole-ext portion of the Guacamole Client - and changes to that are very carefully considered such that they do not needlessly break extensions. Furthermore, there has been discussion in the past couple of months on this mailing list on how we better define versions going forward to make sure that it is clear what versions will break compatibility with extensions. I disagree with your second statement - that it's crazy to make ask people to make "everything" - the architecture of the Guacamole client is such that it is made up of two major components: the Java application, and the AngularJS browser application. It is unrealistic to believe that either of those components can be written in such a way that extending one side would not require also writing the extensions to the other component, at least in some cases. Certainly we try to think about how people will ultimately use the software and anticipate certain requirements, but we cannot anticipate everything or write code that magically allows the software to do things we didn't even consider might be done. Finally, your last statement is absolutely false: "No wonder there are no extensions." There are 8 extensions in the current code (one of which, the JDBC authentication extension, has 3 modules), with at least two more in the works (SAML authentication and QuickConnect). Customizing look & feel ("branding") has been well discussed in the mailing list. And then there are folks like you trying to do things like this with extensions, which is totally possible, even if it isn't as easy as you'd like it to be. > > Again. What would be consider extension for guacamole is ability to > create ONE - in caps ONE - file, which, for example, will have extra > DB fields user want, and list of changes to files and/or variables for > guacamole, which will in turn, being parsed by guacamole, will produce > changes to whatever part or variable was changed. > There should be list of variables, and all and every single thing > which happens and shows is taken from those. > Ask the guys from Apache foundation - they will teach you. > This is, by my definition, configuration, not extension. One file allowing you to change the behavior of software is configuring the software, not extending it. I'm not sure what other software you've seen that your are referencing that behaves this way and calls it an extension, but apparently we differ on how to define that. In any case, it's up to the Guacamole project to define what "extension" means, and we have defined it, and it is well-documented. When the question was first asked (by Joachim) on the mailing list about doing this, Mike gave a very detailed response on what was necessary to accomplish it. You seem to have drawn some conclusions about how easy that was to accomplish, but absolutely no one posted anything that could be interpreted as "change a single file and this will work." > > When one writes software which extends functionality of your software > - it is different type of extension. The ability to use Extensions for > software Guacamole should be what I described in previous paragraph or > very close to it. > Your expectations are unrealistic. You are looking at this software and saying, "It should behave the way I expect it to behave," and then getting angry at and berating us when it doesn't, rather than looking at the software, examining how it works, and saying, "How can I make the software do what I want it to do?" if you approach it from the later position, with an open mind, you will be able to accomplish what you want to accomplish. And, we are happy to help you through the development process - I've come a long way from when I first started messing around with the Guacamole code (at least, I think I have, though I'm certain I have a long way to go :-), and I'm happy to discuss and share ideas and code on how to accomplish the functionality that you are looking for. -Nick
