# HG changeset patch
# User John@Yosemite-PC
# Date 1330788301 18000
# Node ID 6c8f9473b22e255d82295516b8220e0855e0d6f7
# Parent  431ddc8bdb4afb1ed18d2c0d28918806708d0d5f
Notes on list storage keys

diff -r 431ddc8bdb4a -r 6c8f9473b22e Lists.lua
--- a/Lists.lua	Fri Mar 02 23:09:14 2012 -0500
+++ b/Lists.lua	Sat Mar 03 10:25:01 2012 -0500
@@ -9,7 +9,38 @@
 
 -- TODO: rename player
 
-
+-- notes on list storage:
+-- Storing names as I do now is atrocious.
+-- It prevents insertions (twss) to the middle of the list because then it acts
+-- as a side effect onto all the others. ie ABCD -> AXBCD would be phrased as
+-- "insert X and shift down B,C,D" which sucks. BCD haven't really been affected
+-- (yet) because their relative positions to the others are still intact - ie
+-- they are still below A right where they belong. But really X hasn't done
+-- anything to affect their relative standing.
+--
+-- Ok so we can't use names.
+--
+-- We can't use monotonic integers either because it suffers the same problem.
+-- Also consider, randoming in someone to a list of ABCD. Say they roll spot 2.
+-- What if someone else runs a separate raid and also randoms someone into slot
+-- 2? How do you handle that conflict? Difficult. Also, consider this:
+-- List of ABCD on night 1.
+-- Admin 1 on night 2 rolls in 30 new people. ABCD's indexes are shuffled to be
+-- between 1-35.
+-- Admin 2 on night 3 rolls in 5 new ones and people ABCD and PQRST now all have
+-- indexes between 1-9.
+-- When these two are resolved against one another, do the 1-9 peopole end up on
+-- top of the list compared to those other 30? 
+--
+-- Solution:
+-- Need a huge random space with purposely left gaps to leave plenty of room for
+-- conflicts.
+-- So if ABCD had randomed on a space of say, 10,000 and then were sorted into
+-- order, then the next 30 could roll into that same space and have a proper
+-- ordering. Then the next 5, etc.
+--
+-- Handling conflicts:
+--
 
 bsk.lists = {}
 bsk.players = {}