Things that (might) need to be done to RhythmDB in the future. These are merely sketches of shadows of ideas.

Multi-valued properties (artist, album, etc.)

• Probably requires dismantling of the existing tree (genre->artist->album) structure

• Maybe replace that with a single-level index structure (map of value -> list of entries)

• Restrict the set of properties that can have multiple values:
  • genre, artist
  • album, disc number, track number, date? (would need to store these as a tuple, really)
• Add entry flags for each to indicate multiple values are present
  • flag unset; the property pointer is just a pointer to a refstring as normal
  • flag set: the property pointer is a pointer to a string array or something, with the first element holding a combined form ("a, b, c")
• Add rhythmdb_entry_get_strings(), returning the array containing all values .. or something.

Entry-type specific properties

If we're going to convert the existing podcast code into plugin form, entry types will need to be able to register new properties. These properties will need to be usable through normal(ish) queries so that they can be used to perform searches and such. An initial proposal:

Allocate property IDs the same way we allocate entry types. A custom property ID would be a pointer to a structure containing:

• Property name
• Value type (as a GType, I guess)
• Entry type to which the property applies
• Getter function pointer (+ data + destroy-notify)
• Setter function pointer (+ data + destroy-notify)
• If we replace the db tree structure with single-level indices (see above), a flag requesting indexing on this property

This might get slightly messy if the built-in property IDs stayed as small sequential integers.

Values stored in the on-disk db would probably work OK. If the entry type isn't registered, then the entry is stored in the unknown-entry-types map; if the entry type is registered, then the property must be too. This would require a small change to entry type registration, splitting it into entry type creation, followed by registration of properties, then registration.

This should be enough to allow entry-type specific properties to be used in queries. Changes could be propagated as normal, and query conditions could be evaluated easily enough.

Python bindings

The query creation functions all use varargs, which the python binding tools don't support.

The multi-valued and custom property stuff above might cause some problems.

DBus bindings

?