Is amulegui still recommended alongside the new amuleapi Web UI?

[gbcox]

I maintain the aMule package in Fedora. The package currently provides the normal amule application and the headless amuled setup with the new amuleapi Web UI, but it does not build the optional amulegui target.

When selecting the packaged components, my impression was that upstream development was moving toward amuled plus amuleapi for remote administration. Because the new Web UI appears to duplicate most or all of the functionality provided by amulegui, I did not see a clear reason to package and maintain both interfaces.

A Fedora user has now asked about amulegui, so I would appreciate clarification:

• Does amulegui provide significant functionality that is unavailable through the current amuleapi Web UI?
• Are the two interfaces intended to serve materially different use cases, or are they primarily alternative frontends for the same functionality?
• Is amulegui expected to remain actively developed?
• For a distribution package, would upstream recommend providing both, or concentrating on amuleapi unless a specific need for the native remote GUI exists?

For clarity, this comparison concerns the new amuleapi Web UI, not the deprecated legacy amuleweb.

[got3nks]

Thanks for asking rather than assuming. The premise is the part worth correcting first: amuleapi replaces amuleweb, not amulegui. They are different things, and both are maintained.

Does amulegui provide functionality the Web UI does not? A little, and less than you might expect. The Web UI already covers downloads, shared files, search, clients, servers and Kad, categories, preferences, statistics, the aMule log (view, clear and export) and IP-filter reload/update. What it does not have yet is friends and chat/messaging - both are implemented in the REST API, they simply have no frontend views. amulegui mirrors the full desktop UI, so it covers those today.

Different use cases, or alternative frontends? Different deployments. amulegui speaks EC directly and opens no HTTP listener, so there is nothing to expose or put behind a proxy; its cost is the wx/GTK dependency stack. amuleapi is an HTTP service (REST + SSE) with a browser UI, which is what you want for headless machines, phones, or anywhere installing a GTK client is unwelcome. For non-local access it should sit behind a reverse proxy such as nginx.

Is amulegui expected to remain actively developed? Yes. It is actively maintained, not in maintenance-only mode, and not slated for removal.

For a distribution package? Both, if you can carry them. They serve different users rather than competing: amulegui for administering a remote daemon from a desktop session, amuleapi for browser or headless access. If you must pick one for a headless-server package, amuleapi is the reasonable default, but please do not drop amulegui on the assumption that it has been superseded, because it has not.