What are practical applications of Queues?

Would it be nice if Phabricator has an application that can install other applications?

• I have been following Phabricator and its related software stacks for a couple of months now and i must commend the effort of the team behind it. Its not only a base for me as a developer to learn a lot about certain intricacies of software development but also how to better  organize applications that are not related to it. While inspecting the applications within Phabricator i started thinking about a way to automatically install and uninstall applications that are build to run within it, this i figured might help with installing third-party applications developed by other programmers, so that while keeping the core applications third-party applications can be added at will or removed when not needed anymore. Below is the somewhat rough package management i am suggesting of which i have implemented a test-drive for it. Package management Layout Overview: The application responsible for managing third-party application will also have a database to store information about the third-party applications this will help is dealing with two things. Firstly, keep meta information about the application in question, like the author, how to contact him or her,and secondly ,a detailed description of what the application is capable of and the various user permissions or rights of the users of such an application that would be enforced within controllers for the application in question. Below is an illustration of the concept i have for the package management system. Suppose i was to build an application called Derby for instance i would make a directory called derby somewhere on my disk and then with the derby folder will be the following structured layout application --- Like the normal applications you find within Phabricator, this folder will house to files the usual application file that extends PhabricatorApplication class and a package.json file that contains information about the application. The package,json file will be read during the application installer and stored in a db. controller --- The usual controllers for the application will be created within this folder and they must reference the application defined policy- see below for a description of the app policy structure - to filer users of the applications. query--- This folder holds all application specific query classes which extends the PhabricatorQuery class etc. Some of the query classes might need to be passed instance of the user object obtained from the request object, if the is a need to perform user filter within the query class css--- All application related css resource files will be created within this folder and during installation it would be moved to rsrc/css/applications/derby folder before running the static resource packager (celerity_mapper.php). js-- Like the css resources all application related js files will be created within this folder and will be moved to the rsrc/js/applications/derby before running the resource packager (celerity_mapper.php). image-- All application related images will be stored here. This also will be moved during installation to rsrc/image/applications/derby before running the static resource mapper.  data-- All application data that may be needed by the application either during setup or installation will be stored in this folder as json to be read by the application patch manager. This data foler will be moved to resources/data/derby during the installation. Here you can also place configuration data that would needed to setup the application. patch-- This folder will contain tow files, the derby.sql and the derby.php files respectively. The derby.sql file will be executed during installation through the SQL patch management system or the storage manager, while the derby.php will be executed to read json data from the data folder above and setup records needed by the application.This php file will be executed also the patch manager as well. policy-- The policy file will be an xml file containing application defined rules that will be configured by the system admin to define who and who sould use certain features of the application and who should not. This file will be read and executed during installation as well by the installer. This would require storing policies in database against the application unique id. The installation process will be through the commandline, i have tried to see if it would be possible through a web interface but it seemed that for me to use the Future for this i need to known the absolute path to php itself. so the command line option is better. the command line will involve a simple command like (run from within scripts folder) phinstaller install derby assuming that we have a __plugin__ folder within which all new third-party applications are stored. This folder will be excluded from linting engines so that they don't get included into the library map. This is just a suggestions thanks.

• Answer:

  (I'll respond briefly here; if you want to discuss this in detail, consider filing a task in Maniphest on http://secure.phabricator.com.) We're generally moving in this direction, but doing so in small steps for now. The biggest problem is API stability: as soon as we come up with a reasonably decent way to add new applications, we need to do more to preserve backward compatibility across API changes. For now, we make a lot of API changes, so this would slow things down. The best thing we could build today wouldn't be very good, and we'd probably burn a lot of time and goodwill if we tried to build an ecosystem right now. We've made a lot of progress toward this goal, especially in the last few months, and are fixing coupling in the first-party applications so they are at parity with potential future third-party applications and can be uninstalled (with some exceptions for applications which provide fundamental/core functionality, like "People", "Auth", and the "Applications" meta-application). However, there's a lot of coupling remaining. Overall, we're headed in this direction, but we probably won't get there in a serious way before later this year.