Thank you for reply Nick and for contributions to Guacamole. Indeed I might have jumped to conclusions too fast. From this discussion I've read (http://apache-guacamole-general-user-mailing-list.2363388.n4.nabble.com/Extension-showing-VM-status-td2955.html) and fast go-through the documentation the conclusion of questionable usability of guacamole extension approach had been made. By no means I am trying to push some hard lines.
We are simple people dealing with software in Open Source community. And continuing as We: we love to have something we can use or integrate in different projects etc. I understand that Guacamole is mainly the core and javascript viewer, but it also has interface and database which we want o utilize. It would be great to have ability to make extensions without going through all 9 circles. OneCloud extensions are more like a separate software with different purpose - Mail IMAP clients, Chats etc. It is surly not what we are talking about for Guacamole extensions. Those 8 extensions are auth extensions you guys made which could as well been just a part of the Guacamole and changed by setting. To clarify what I mean by such ability and extensions with example. Lets say the guy want to make MAC computers show different icon from Windows computer. He will create the file: local.d/guacamole.extension.macicons: [database.add] new.connection.fields.name='macorwin' new.connection.fields.type=char(3) new.connection.fields.default='std' new.connection.fields.allowed-values='std,mac,win' [interface.connection.setting.add] new.setting.name='Mac or Win' new.setting.type=list new.setting.allowed-values='std,mac,win' [interface.tree] interface.tree.connection.image=connection.fields.macorwin.value+'.png' Guacamole builder, while going through this local settings adds DB field to Connections and Setting in settings page, altering connection tree-view to have specific .png as icon And no one need to write html, css etc. Simple. And it seems that you have all parameters already documented in API section. Standard way we change something are files and, if speed needed, SQL tables. Or maybe there is the way to do this already which I missed. Please mark me. v On Sun, Mar 25, 2018 at 10:19 PM, Nick Couchman <[email protected]> wrote: > 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
