chiark / gitweb /
Use disorder-choose to pick random tracks.
[disorder] / doc / disorder_protocol.5.in
... / ...
CommitLineData
1.\"
2.\" Copyright (C) 2004-2008 Richard Kettlewell
3.\"
4.\" This program is free software; you can redistribute it and/or modify
5.\" it under the terms of the GNU General Public License as published by
6.\" the Free Software Foundation; either version 2 of the License, or
7.\" (at your option) any later version.
8.\"
9.\" This program is distributed in the hope that it will be useful, but
10.\" WITHOUT ANY WARRANTY; without even the implied warranty of
11.\" MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
12.\" General Public License for more details.
13.\"
14.\" You should have received a copy of the GNU General Public License
15.\" along with this program; if not, write to the Free Software
16.\" Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307
17.\" USA
18.\"
19.TH disorder_protocol 5
20.SH NAME
21disorder_protocol \- DisOrder communication protocol
22.SH DESCRIPTION
23The DisOrder client and server communicate via the protocol described
24in this man page.
25.PP
26The protocol is liable to change without notice.
27You are recommended to check the implementation before believing this document.
28.SH "GENERAL SYNTAX"
29Everything is encoded using UTF-8.
30See
31.B "CHARACTER ENCODING"
32below for more detail on character encoding issues.
33.PP
34Commands and responses consist of a line perhaps followed (depending on the
35command or response) by a body.
36.PP
37The line syntax is the same as described in \fBdisorder_config\fR(5) except
38that comments are prohibited.
39.PP
40Bodies borrow their syntax from RFC821; they consist of zero or more ordinary
41lines, with any initial full stop doubled up, and are terminated by a line
42consisting of a full stop and a line feed.
43.SH COMMANDS
44Commands always have a command name as the first field of the line; responses
45always have a 3-digit response code as the first field.
46See below for more details about this field.
47.PP
48All commands require the connection to have been already authenticated unless
49stated otherwise.
50If not stated otherwise, the \fBread\fR right is sufficient to execute
51the command.
52.PP
53Neither commands nor responses have a body unless stated otherwise.
54.TP
55.B adduser \fIUSERNAME PASSWORD \fR[\fIRIGHTS\fR]
56Create a new user with the given username and password.
57The new user's rights list can be specified; if it is not
58then the \fBdefault_rights\fR setting applies instead.
59Requires the \fBadmin\fR right, and only works on local
60connections.
61.TP
62.B allfiles \fIDIRECTORY\fR [\fIREGEXP\fR]
63List all the files and directories in \fIDIRECTORY\fR in a response body.
64If \fIREGEXP\fR is present only matching files and directories are returned.
65.TP
66.B confirm \fICONFIRMATION
67Confirm user registration.
68\fICONFIRMATION\fR is as returned from \fBregister\fR below.
69This command can be used without logging in.
70.TP
71.B cookie \fICOOKIE
72Log a user back in using a cookie created with \fBmake\-cookie\fR.
73The response contains the username.
74.TP
75.B deluser \fIUSERNAME
76Delete the named user.
77Requires the \fBadmin\fR right, and only works on local connections.
78.TP
79.B dirs \fIDIRECTORY\fR [\fIREGEXP\fR]
80List all the directories in \fIDIRECTORY\fR in a response body.
81If \fIREGEXP\fR is present only matching directories are returned.
82.TP
83.B disable \fR[\fBnow\fR]
84Disable further playing.
85If the optional \fBnow\fR argument is present then the current track
86is stopped.
87Requires the \fBglobal prefs\fR right.
88.TP
89.B edituser \fIUSERNAME PROPERTY VALUE
90Set a user property.
91With the \fBadmin\fR right any username and property may be specified.
92Otherwise the \fBuserinfo\fR right is required and only the
93\fBemail\fR and \fBpassword\fR properties may be set.
94.TP
95.B enable
96Re-enable further playing, and is the opposite of \fBdisable\fR.
97Requires the \fBglobal prefs\fR right.
98.TP
99.B enabled
100Report whether playing is enabled.
101The second field of the response line will be \fByes\fR or \fBno\fR.
102.TP
103.B exists \fITRACK\fR
104Report whether the named track exists.
105The second field of the response line will be \fByes\fR or \fBno\fR.
106.TP
107.B files \fIDIRECTORY\fR [\fIREGEXP\fR]
108List all the files in \fIDIRECTORY\fR in a response body.
109If \fIREGEXP\fR is present only matching files are returned.
110.TP
111.B get \fITRACK\fR \fIPREF\fR
112Getsa preference value.
113On success the second field of the response line will have the value.
114.IP
115If the track or preference do not exist then the response code is 555.
116.TP
117.B get\-global \fIKEY\fR
118Get a global preference.
119.IP
120If the preference does not exist then the response code is 555.
121.TP
122.B length \fITRACK\fR
123Get the length of the track in seconds.
124On success the second field of the response line will have the value.
125.TP
126.B log
127Send event log messages in a response body.
128The command will never terminate.
129Any further data sent to the server will be discarded (explicitly;
130i.e. it will not accumulate in a buffer somewhere).
131.IP
132See \fBEVENT LOG\fR below for more details.
133.TP
134.B make\-cookie
135Returns an opaque string that can be used by the \fBcookie\fR command to log
136this user back in on another connection (until the cookie expires).
137.TP
138.B move \fITRACK\fR \fIDELTA\fR
139Move a track in the queue.
140The track may be identified by ID (preferred) or name (which might cause
141confusion if it's there twice).
142\fIDELTA\fR should be an negative or positive integer and indicates how
143many steps towards the head of the queue the track should be moved.
144.IP
145Requires one of the \fBmove mine\fR, \fBmove random\fR or \fBmove any\fR rights
146depending on how the track came to be added to the queue.
147.TP
148.B moveafter \fITARGET\fR \fIID\fR ...
149Move all the tracks in the \fIID\fR list after ID \fITARGET\fR.
150If \fITARGET\fR is the empty string then the listed tracks are put
151at the head of the queue.
152If \fITARGET\fR is listed in the ID list then the tracks are moved
153to just after the first non-listed track before it, or to the head if there is
154no such track.
155.IP
156Requires one of the \fBmove mine\fR, \fBmove random\fR or \fBmove any\fR rights
157depending on how the tracks came to be added to the queue.
158.TP
159.B new \fR[\fIMAX\fR]
160Send the most recently added \fIMAX\fR tracks in a response body.
161If the argument is ommitted, the \fBnew_max\fR most recent tracks are
162listed (see \fBdisorder_config\fR(5)).
163.TP
164.B nop
165Do nothing.
166Used by
167.BR disobedience (1)
168as a keepalive measure.
169This command does not require authentication.
170.TP
171.B part \fITRACK\fR \fICONTEXT\fI \fIPART\fR
172Get a track name part.
173Returns an empty string if a name part cannot be constructed.
174.IP
175.I CONTEXT
176is one of
177.B sort
178or
179.B display
180and
181.I PART
182is usually one of
183.BR artist ,
184.B album
185or
186.BR title .
187.TP
188.B pause
189Pause the current track.
190Requires the \fBpause\fR right.
191.TP
192.B play \fITRACK\fR
193Add a track to the queue.
194The response contains the queue ID of the track.
195Requires the \fBplay\fR right.
196.TP
197.B playing
198Report what track is playing.
199.IP
200If the response is \fB252\fR then the rest of the response line consists of
201track information (see below).
202.IP
203If the response is \fB259\fR then nothing is playing.
204.TP
205.B prefs \fBTRACK\fR
206Send back the preferences for \fITRACK\fR in a response body.
207Each line of the response has the usual line syntax, the first field being the
208name of the pref and the second the value.
209.TP
210.B queue
211Send back the current queue in a response body, one track to a line, the track
212at the head of the queue (i.e. next to be be played) first.
213See below for the track information syntax.
214.TP
215.B random\-disable
216Disable random play (but don't stop the current track).
217Requires the \fBglobal prefs\fR right.
218.TP
219.B random\-enable
220Enable random play.
221Requires the \fBglobal prefs\fR right.
222.TP
223.B random\-enabled
224Report whether random play is enabled.
225The second field of the response line will be \fByes\fR or \fBno\fR.
226.TP
227.B recent
228Send back the current recently-played list in a response body, one track to a
229line, the track most recently played last.
230See below for the track information syntax.
231.TP
232.B reconfigure
233Request that DisOrder reconfigure itself.
234Requires the \fBadmin\fR right.
235.TP
236.B register \fIUSER PASSWORD EMAIL
237Register a new user.
238Requires the \fBregister\fR right.
239The result contains a confirmation string; the user will be be able
240to log in until this has been presented back to the server via the
241\fBconfirm\fR command.
242.TP
243.B reminder \fIUSER\fR
244Send a password reminder to \fIUSER\fR.
245If the user has no valid email address, or no password, or a
246reminder has been sent too recently, then no reminder will be sent.
247.TP
248.B remove \fIID\fR
249Remove the track identified by \fIID\fR.
250Requires one of the \fBremove mine\fR, \fBremove random\fR or
251\fBremove any\fR rights depending on how the
252track came to be added to the queue.
253.TP
254.B rescan
255Rescan all roots for new or obsolete tracks.
256Requires the \fBrescan\fR right.
257.TP
258.B resolve \fITRACK\fR
259Resolve a track name, i.e. if this is an alias then return the real track name.
260.TP
261.B resume
262Resume the current track after a \fBpause\fR command.
263Requires the \fBpause\fR right.
264.TP
265.B revoke \fBcookie\fR
266Revoke a cookie previously created with \fBmake\-cookie\fR.
267It will not be possible to use this cookie in the future.
268.TP
269.B rtp\-address
270Report the RTP broadcast (or multicast) address, in the form \fIADDRESS
271PORT\fR.
272This command does not require authentication.
273.TP
274.B scratch \fR[\fIID\fR]
275Remove the track identified by \fIID\fR, or the currently playing track if no
276\fIID\fR is specified.
277Requires one of the \fBscratch mine\fR, \fBscratch random\fR or
278\fBscratch any\fR rights depending on how the track came to be
279added to the queue.
280.TP
281.B search \fITERMS\fR
282Search for tracks matching the search terms.
283The results are put in a response body, one to a line.
284.IP
285The search string is split in the usual way, with quoting supported, into a
286list of terms.
287Only tracks matching all terms are included in the results.
288.IP
289Any terms of the form \fBtag:\fITAG\fR limits the search to tracks with that
290tag.
291.IP
292All other terms are interpreted as individual words which must be present in
293the track name.
294.IP
295Spaces in terms don't currently make sense, but may one day be interpreted to
296allow searching for phrases.
297.TP
298.B \fBset\fR \fITRACK\fR \fIPREF\fR \fIVALUE\fR
299Set a preference.
300Requires the \fBprefs\fR right.
301.TP
302.B set\-global \fIKEY\fR \fIVALUE\fR
303Set a global preference.
304Requires the \fBglobal prefs\fR right.
305.TP
306.B stats
307Send server statistics in plain text in a response body.
308.TP
309.B \fBtags\fR
310Send the list of currently known tags in a response body.
311.TP
312.B \fBunset\fR \fITRACK\fR \fIPREF\fR
313Unset a preference.
314Requires the \fBprefs\fR right.
315.TP
316.B \fBunset\-global\fR \fIKEY\fR
317Unset a global preference.
318Requires the \fBglobal prefs\fR right.
319.TP
320.B user \fIUSER\fR \fIRESPONSE\fR
321Authenticate as \fIUSER\fR.
322See
323.B AUTHENTICATION
324below.
325.TP
326.B users
327Send the list of currently known users in a response body.
328.TP
329.B version
330Send back a response with the server version as the second field.
331.TP
332.B volume \fR[\fILEFT\fR [\fIRIGHT\fR]]
333Get or set the volume.
334.IP
335With zero parameters just gets the volume and reports the left and right sides
336as the 2nd and 3rd fields of the response.
337.IP
338With one parameter sets both sides to the same value.
339With two parameters sets each side independently.
340Setting the volume requires the \fBvolume\fR right.
341.SH RESPONSES
342Responses are three-digit codes.
343The first digit distinguishes errors from succesful responses:
344.TP
345.B 2
346Operation succeeded.
347.TP
348.B 5
349Operation failed.
350.PP
351The second digit breaks down the origin of the response:
352.TP
353.B 0
354Generic responses not specific to the handling of the command.
355Mostly this is parse errors.
356.TP
357.B 1
35851x errors indicate that the user had insufficient rights for the command.
359.TP
360.B 3
361Authentication responses.
362.TP
363.B 5
364Responses specific to the handling of the command.
365.PP
366The third digit provides extra information about the response:
367.TP
368.B 0
369Text part is just commentary.
370.TP
371.B 1
372Text part is a constant result e.g. \fBversion\fR.
373.TP
374.B 2
375Text part is a potentially variable result.
376.TP
377.B 3
378Text part is just commentary; a dot-stuffed body follows.
379.TP
380.B 4
381Text part is just commentary; an indefinite dot-stuffed body follows.
382(Used for \fBlog\fR.)
383.TP
384.B 5
385Used with "normal" errors, for instance a preference not being found.
386The text part is commentary.
387.TP
388.B 9
389The text part is just commentary (but would normally be a response for this
390command) e.g. \fBplaying\fR.
391.PP
392Result strings (not bodies) intended for machine parsing (i.e. xx1 and xx2
393responses) are quoted.
394.SH AUTHENTICATION
395When a connection is made the server sends a \fB231\fR response before any
396command is received.
397This contains a protocol generation, an algorithm name and a
398challenge encoded in hex, all separated by whitespace.
399.PP
400The current protocol generation is \fB2\fR.
401.PP
402The possible algorithms are (currently) \fBsha1\fR, \fBsha256\fR, \fBsha384\fR
403and \fBsha512\fR.
404\fBSHA1\fR etc work as synonyms.
405.PP
406The \fBuser\fR response consists of the selected hash of the user's password
407concatenated with the challenge, encoded in hex.
408.SH "TRACK INFORMATION"
409Track information is encoded in a line (i.e. using the usual line syntax) as
410pairs of fields.
411The first is a name, the second a value.
412The names have the following meanings:
413.TP 12
414.B expected
415The time the track is expected to be played at.
416.TP
417.B id
418A string uniquely identifying this queue entry.
419.TP
420.B played
421The time the track was played at.
422.TP
423.B scratched
424The user that scratched the track.
425.TP
426.B state
427The current track state.
428Valid states are:
429.RS
430.TP 12
431.B failed
432The player failed (exited with nonzero status but wasn't scratched).
433.TP
434.B isscratch
435The track is actually a scratch.
436.TP
437.B no_player
438No player could be found for the track.
439.TP
440.B ok
441The track was played without any problems.
442.TP
443.B scratched
444The track was scratched.
445.TP
446.B started
447The track is currently playing.
448.TP
449.B unplayed
450In the queue, hasn't been played yet.
451.TP
452.B quitting
453The track was terminated because the server is shutting down.
454.RE
455.TP
456.B submitter
457The user that submitted the track.
458.TP
459.B track
460The filename of the track.
461.TP
462.B when
463The time the track was added to the queue.
464.TP
465.B wstat
466The wait status of the player in decimal.
467.SH NOTES
468Times are decimal integers using the server's \fBtime_t\fR.
469.PP
470For file listings, the regexp applies to the basename of the returned file, not
471the whole filename, and letter case is ignored.
472\fBpcrepattern\fR(3) describes the regexp syntax.
473.PP
474Filenames are in UTF-8 even if the collection they come from uses some other
475encoding - if you want to access the real file (in such cases as the filenames
476actually correspond to a real file) you'll have to convert to whatever the
477right encoding is.
478.SH "EVENT LOG"
479The event log consists of lines starting with a hexadecimal timestamp and a
480keyword followed by (optionally) parameters.
481The parameters are quoted in the usual DisOrder way.
482Currently the following keywords are used:
483.TP
484.B completed \fITRACK\fR
485Completed playing \fITRACK\fR
486.TP
487.B failed \fITRACK\fR \fIERROR\fR
488Completed playing \fITRACK\fR with an error status
489.TP
490.B moved \fIUSER\fR
491User \fIUSER\fR moved some track(s).
492Further details aren't included any more.
493.TP
494.B playing \fITRACK\fR [\fIUSER\fR]
495Started playing \fITRACK\fR.
496.TP
497.B queue \fIQUEUE-ENTRY\fR...
498Added \fITRACK\fR to the queue.
499.TP
500.B recent_added \fIQUEUE-ENTRY\fR...
501Added \fIID\fR to the recently played list.
502.TP
503.B recent_removed \fIID\fR
504Removed \fIID\fR from the recently played list.
505.TP
506.B removed \fIID\fR [\fIUSER\fR]
507Queue entry \fIID\fR was removed.
508This is used both for explicit removal (when \fIUSER\fR is present)
509and when playing a track (when it is absent).
510.TP
511.B rescanned
512A rescan completed.
513.TP
514.B scratched \fITRACK\fR \fIUSER\fR
515\fITRACK\fR was scratched by \fIUSER\fR.
516.TP
517.B state \fIKEYWORD\fR
518Some state change occurred.
519The current set of keywords is:
520.RS
521.TP
522.B completed
523The current track completed successfully.
524.TP
525.B disable_play
526Playing was disabled.
527.TP
528.B disable_random
529Random play was disabled.
530.TP
531.B enable_play
532Playing was enabled.
533.TP
534.B enable_random
535Random play was enabled.
536.TP
537.B failed
538The current track failed.
539.TP
540.B pause
541The current track was paused.
542.TP
543.B playing
544A track started playing.
545.TP
546.B resume
547The current track was resumed.
548.TP
549.B scratched
550The current track was scratched.
551.PP
552To simplify client implementation, \fBstate\fR commands reflecting the current
553state are sent at the start of the log.
554.RE
555.TP
556.B volume \fILEFT\fR \fIRIGHT\fR
557The volume changed.
558.PP
559.IR QUEUE-ENTRY ...
560is as defined in
561.B "TRACK INFORMATION"
562above.
563.SH "CHARACTER ENCODING"
564All data sent by both server and client is encoded using UTF-8.
565Moreover it must be valid UTF-8, i.e. non-minimal sequences are not
566permitted, nor are surrogates, nor are code points outside the
567Unicode code space.
568.PP
569There are no particular normalization requirements on either side of the
570protocol.
571The server currently converts internally to NFC, the client must
572normalize the responses returned if it needs some normalized form for further
573processing.
574.PP
575The various characters which divide up lines may not be followed by combining
576characters.
577For instance all of the following are prohibited:
578.TP
579.B o
580LINE FEED followed by a combining character.
581For example the sequence LINE FEED, COMBINING GRAVE ACCENT is never permitted.
582.TP
583.B o
584APOSTROPHE or QUOTATION MARK followed by a combining character when used to
585delimit fields.
586For instance a line starting APOSTROPHE, COMBINING CEDILLA is prohibited.
587.IP
588Note that such sequences are not prohibited when the quote character cannot be
589interpreted as a field delimiter.
590For instance APOSTROPHE, REVERSE SOLIDUS, APOSTROPHE, COMBINING CEDILLA,
591APOSTROPHE would be permitted.
592.TP
593.B o
594REVERSE SOLIDUS (BACKSLASH) followed by a combining character in a quoted
595string when it is the first character of an escape sequence.
596For instance a line starting APOSTROPHE, REVERSE SOLIDUS, COMBINING TILDE
597is prohibited.
598.IP
599As above such sequences are not prohibited when the character is not being used
600to start an escape sequence.
601For instance APOSTROPHE, REVERSE SOLIDUS, REVERSE SOLIDS, COMBINING TILDE,
602APOSTROPHE is permitted.
603.TP
604.B o
605Any of the field-splitting whitespace characters followed by a combining
606character when not part of a quoted field.
607For instance a line starting COLON, SPACE, COMBINING CANDRABINDU is prohibited.
608.IP
609As above non-delimiter uses are fine.
610.TP
611.B o
612The FULL STOP characters used to quote or delimit a body.
613.PP
614Furthermore none of these characters are permitted to appear in the context of
615a canonical decomposition (i.e. they must still be present when converted to
616NFC).
617In practice however this is not an issue in Unicode 5.0.
618.PP
619These rules are consistent with the observation that the split() function is
620essentially a naive ASCII parser.
621The implication is not that these sequences never actually appear in
622the protocol, merely that the server is not required to honor them in
623any useful way nor be consistent between versions: in current
624versions the result will be lines and fields that start with combining
625characters and are not necessarily split where you expect, but future versions
626may remove them, reject them or ignore some or all of the delimiters that have
627following combining characters, and no notice will be given of any change.
628.SH "SEE ALSO"
629\fBdisorder\fR(1),
630\fBtime\fR(2),
631\fBdisorder\fR(3),
632\fBpcrepattern\fR(3)
633\fBdisorder_config\fR(5),
634\fBdisorderd\fR(8),
635\fButf8\fR(7)
636.\" Local Variables:
637.\" mode:nroff
638.\" fill-column:79
639.\" End: