yet more readme work. Still much to do

README.md

@@ -6,18 +6,24 @@ early stage, and you shouldn't particularly expect anything
 to work properly. Its primary purpose is as part of the
 un_chapeau Mastodon server.
 
+At present we aren't supporting local clients posting to a
+user's outbox, though we should eventually.
+
 Not everything described herein has actually been implemented.
 
-django_kepi.views.ActivityObjectResponse
-----------------------------------------
+django_kepi.responses.ActivityObjectResponse
+--------------------------------------------
 This renders a Django object into ActivityStreams form.
 It calls the object's activity_get() method in order to
 serialise it. If that method throws TombstoneException,
 a Tombstone will be generated instead, and the HTTP
 result code will be set to 410 (Gone).
 
-Collections
------------
+Some of these objects, such as Likes, will belong to django_kepi.
+Other kinds, such as Persons and Articles, will belong to other apps.
+
+django_kepi.responses.CollectionResponse
+----------------------------------------
 These are based on ordinary Django ordered querysets.
 (Responses? Views?)
 
@@ -41,6 +47,10 @@ If activity_get() is called during producing a Collection,
 and throws TombstoneException, the object will be represented
 by a Tombstone object, but the HTTP status code will be unaffected.
 
+Throwing TombstoneException doesn't remove the object's record from
+NamedObjects, because we'll still need to find the Tombstone when
+someone asks for it.
+
 django_kepi.models.resolve()
 ----------------------------
 Takes a URL identifier, and returns the object it refers to,
@@ -55,11 +65,17 @@ we run the path through django.urls.resolve() to find the view function.
 (XXX This won't work. NamedObject finds us an object, and
 d.u.resolve() gets us a view function. They need to be the same.)
 
-Lastly, XXX fallback.
+XXX Fallback function to handle fetching, etc, per Activity type
 
 XXX explain about how remote objects will have local proxy objects
 XXX explain how these proxy objects should never be served
 
+XXX There's actually four things we might want to do to an object:
+XXX  Create: ID + fields -> new object (serialised)
+XXX  Get: ID -> existing object (deserialised)
+XXX  Update: ID + fields -> existing object (partially serialised)
+XXX  Delete: ID -> no object (or Tombstone)
+
 django_kepi.models.QuarantinedMessage
 -------------------------------------
 An activity message we've received from another server, but
@@ -89,6 +105,8 @@ django_kepi.models.NamedObject
 This table maps URL identifiers to Django objects,
 using the contenttypes mechanism.
 It also keeps track of the object's ActivityObject type.
+It keeps a timestamp, so the record can fade from the cache
+(but we don't actually do that at present).
 
 Any object we know about on a remote server must be listed in
 this table. Objects on this server *may* be listed
@@ -106,3 +124,16 @@ constitutes a Follow request.
 
 Activities have a "valid" flag, because they can be undone
 by subsequent Activities of type Undo.
+
+django_kepi.views.ActivityView
+------------------------------
+A class view which displays a django_kepi.models.Activity,
+given its UUID. Only our own Activities will be displayed.
+
+django_kepi.views.CollectionView
+--------------------------------
+A view of a queryset, based on django_kepi.responses.CollectionResponse.
+
+Outgoing Activities
+-------------------
+....