User:Amc1/planned developments

From AzureusWiki

This is just about my plans - rather than anyone else in the Azureus team.

Contents 1 File handling capabilities 2 Download bars 3 Disk Manager stuff (work on with parg) 4 Protocol extension stuff 5 Plugin Javadoc 6 DownloadManagerState 7 Plugin menu stuff 8 Real big UI stuff 9 Torrent removal 10 Azureus 1 11 Queueing options 11.1 Minimum upload speed 11.2 Removing / Overriding First Priority 12 Plugins 12.1 Download Focus plugin 12.2 Jython plugin 13 Tracker-based queueing plugin 14 Oddities 15 Unsorted

File handling capabilities

• File handling plugin
  •  !az incomplete file extensions (requires core work too)
  • Move incomplete / DND files out of the way so only complete files show up.

Download bars

• Individual config section for it
• Option to include status icon
  • Plugin API code to allow status icon to be overridden
• Configurable indicators
  • Remaining download for transfers bar
  • [request] auto speed limit info

Disk Manager stuff (work on with parg)

• Remember file size and file date to detect changes to either and force rechecks.

Protocol extension stuff

• Add full LTEP support. Maybe.
• Sort out the silly message padding stuff as version number for Az extension messages.
• Fix the encoding used for AzMP (presumably UTF-8)
• Move the priority stuff to be attributes of the extended message itself (like it said it should be).
• Abstract some of the extension message code stuff to a "base" extension package - LTEP and AZMP would extend from it.
• Create an abstract peer exchange message type, so both types of almost-identical PEX could inherit from it.
• Provide the ability for Az extension messages to indicate if they want to allow themselves to be padded or not (Natter would be an obvious example of something that wouldn't want this)
• If LTEP support was added, add in plugin API support to indicate the extension message should be broadcast over LTEP.
  • That would need ability to disable / enable extension to though.

Plugin Javadoc

• Document some listener classes
  • TorrentManagerListener

DownloadManagerState

Add lightweight listeners for attribute changes...

• Listeners get called for write and read changes - provide just write listeners.
• Listeners get called for all attribute changes, not just ones they are interested in.
• Listeners get passed "events". The DMS itself creates an event object, and then the plugin API uses its own event object.

Plugin menu stuff

• Option to add table columns to download specific views (that's trickier to do that menus)

Real big UI stuff

• Tags (as opposed to categories)
• uTorrent style view (downloads at top, details at bottom)
• Configurable pre-defined filters ("all active", "downloads over 2 gb with share ratio over 1.5")

Torrent removal

• Configurable option to determine what the "default" remove behaviour is
• Requires plugin API changes, menu changes, icon bar changes

Azureus 1

Don't forget to release it!

Queueing options

Minimum upload speed

• Consider removing the minimum upload slot idea (though such logic is still likely to remain)

Removing / Overriding First Priority

• OK - not removing it.
• Allow torrents to be explicitly given first priority? Probably not.
• Maybe no support at all.

Plugins

• Change tracker plugin
• Pause controller plugin (partially done)

Download Focus plugin

• Work with uploads!
• Properly record whether starts were forced or not
• Provide option to force starts or not (for download and upload) and whether you want to stop after focus (when does an upload go out of focus?)
• Allow multiple things to be focused at the same time.
• For downloads, allow selection of what things should be paused:
  • All transfers.
  • All other downloads.
  • All non-forced transfers.
  • All non-forced downloads.
• Allow appending to the focus 'queue'.
• Display download bars.
• Do selective pausing...
• Pause new downloads added?
• Focus column!
• Alert user when you stop and start focus?
• Resume downloads in non-SWT thread.
• Consider first priority downloads too.
• Some sort of persistency handling.
• NO DOING FOCUSED FILE DOWNLOADING - THAT IS NOT WHAT THE PLUGIN IS FOR

Jython plugin

• Do IPC stuff for remote method invocation
  • Consider whether you share an interpreter for that or not - you don't want one interpreter per invocation

Tracker-based queueing plugin

• Automatically sort uploads by tracker.
• Determining whether an upload should start would be difficult...
  • We can determine if all the slots are being used by FP torrents
  • We could even allocate ourselves (maybe core support needed) ourselves an upload slot to see one of our torrents get used.
  • Except that we wouldn't want that slot to be taken up by a torrent ranked lower than... say... where the FP ones are.
  • So maybe it would be something like an "optimistic upload".
  • Make sure that there is a spare slot for at least one queued torrent
  • Needs more thought...

Oddities

• See if plugin API download moving is done the same way as moving by core - may explain some behaviour...
• Force starting and then stopping paused torrents keeps them paused, do we want that?

Unsorted

• Add support for null attribute DMSattr listeners.
• Remove (completely) the old DMSStateListeners.
• Put in the popup code to find out what plugins are using the old property listeners.
• Customisable display formatters for date, datetime, time.
• Get the generate crash debug log could to use the status mailer plugin?
• Change some log behaviour - identification.log and update.log, might need to be careful of multiple log files with same names for debug log generator...
• Table columns and other places which present statistical data might want to consider the wanted-data size (i.e. exclude DND's) rather than the torrent-data size.