Eventually, much of the logic currently in list/controller.go and list/bifrost.go will be applicable to other bits of the server, such as the multiplexer. There's nothing particularly tying much of it to working with lists.

Obviously, we don't want to generalise too fast too soon, but it makes sense to think about doing so in the future.

Selection is how we tell the connected player which track to load. It makes no sense for a text item to be selectable, so we should disallow it.

This needs two changes:

• Stop the user from manually selecting a text item
• Stop autoselect from selecting a text item (it should just skip right over it)

When a new Bifrost is spawned on a client, it should send OHAI, IAMA, and initial dump responses through the response channel.

Currently, when someone presses Ctrl-C in the baps3d console, it exits the program's main function without waiting for the controller etc. to shut down gracefully. This is not ideal =p

We're using fmt.Errorf for errors, which is bad for the following two reasons:

• For errors we're going to send back to the client as Bifrost messages, we can't tell whether it's a problem with the message (ACK WHAT) or our internal state (ACK FAIL);
• Really, the errors should be more structured, and should be converted to Bifrost-friendly format by the Bifrost handling logic for each part of the server.

This is an open question, since there are eleventy zillion different ways to handle errors in Go. Does anyone have any suggestions?

At the least, I'm thinking of just having an error type, and maybe a Blameable interface that lets us decide whether it's a what or a fail.

For baps3d to handle BAPS3 lists, it actually needs to support load requests in the list controller.
list.List already has a method Add that does most of the legwork---this is mostly just connecting it up to the controller logic.

• Handle file load floadl index hash path
  • Add request into list/requests.go
  • Add handler into handleRequest etc. in list/controller.go using c.list as the List
  • Add Bifrost message marshalling logic into list/bifrost.go
• Handle text load tloadl index hash contents
  • Add request into list/requests.go
  • Add handler into handleRequest etc. in list/controller.go using c.list as the List
  • Add Bifrost message marshalling logic into list/bifrost.go

The baps3 spec is incomplete with regards to file and text loads, so that could do with updating. Off the top of my head, what the server should do is:

1. If the given hash is already being used, return an error (should be an ACK WHAT response, just return the error inside the AckResponse for now);
2. We insert above the given index, so if the index isn't in the range 0...len(list) then return an error;
3. Insert the item;
4. Broadcast FLOADL (or TLOADL) index hash contents---these responses already exist for handling dump requests;
5. Broadcast COUNTL new-list-count---this response also already exists.

This is no longer the official URY BAPS3 project, though at the moment I still intend to work on it in my spare time.

A new name that doesn't refer to BAPS would be nice.

baps3d currently only communicates to stdin through a console readline. Obviously, it'll need to talk to Bifrost clients on TCP, but we haven't implemented that yet.

Much of the same logic the console currently uses will help in making the TCP server. What will need to be worked out is the best way of handling multiple clients---the controller has half-implemented support for multiple clients but this is more so that it can have the console, TCP server, and eventually downstream player attached.

TCP servers are the bread and butter of Go, so there should be some good examples in the wild of how to do them.