Merge TODOs
This commit is contained in:
parent
3a303015f8
commit
b7bfaf02c9
|
@ -1,59 +0,0 @@
|
|||
Cope with possibility of duplicate uuid, in e.g. queue/fanout/direct.
|
||||
If a subscription token matches an existing subscription, there's a
|
||||
collision, so choose a new token until there's no collision.
|
||||
|
||||
SAX-style sexp reader/writer, so that we can do something sensible for
|
||||
enormous (e.g. gigabyte-sized) messages.
|
||||
|
||||
The "meta" exchange probably wants to be a topic exchange. Or
|
||||
something.
|
||||
|
||||
The "meta" exchange probably wants to emit how-things-are-now messages
|
||||
when people subscribe to it, to get them started; a kind of
|
||||
last-value-cache type thing.
|
||||
|
||||
Website
|
||||
- http://www.flickr.com/photos/elemishra/158211069/
|
||||
|
||||
Switch from indirect scheduling to direct scheduling
|
||||
- before, on walk: 173kHz test1/test3
|
||||
- after, no change. Probably because we only have a single thread
|
||||
active in the system when running test1/test3, so every time some
|
||||
work comes in, it baton-passes to the next guy in the chain. The
|
||||
change *would* be an improvement but we have a separate worklist
|
||||
(to process now) and runlist (to process after polling for events
|
||||
once) so it always goes back to the scheduler because the worklist
|
||||
is never longer than one.
|
||||
- Revisit once we start testing multiple concurrent streams.
|
||||
|
||||
|
||||
Extension to Sexps:
|
||||
|
||||
- ! <simplestring> <value> : binds the simplestring to the value when
|
||||
seen. Note that the new binding for simplestring is NOT in scope
|
||||
during parsing of the value, so no circular data can be constructed
|
||||
this way. Any previous binding is discarded *after* the value is
|
||||
completely read.
|
||||
|
||||
- ? <simplestring> : retrieves the bound value of the simplestring.
|
||||
|
||||
So
|
||||
!1:a11:hello world(?1:a1: ?1:a1: ?1:a)
|
||||
is equivalent to
|
||||
(11:hello world1: 11:hello world1: 11:hello world)
|
||||
|
||||
And, more to the point, after a receiver has seen
|
||||
!1:a36:af49f5dc-0454-4ba1-9f48-a55e9c10ee35
|
||||
then a simple
|
||||
?1:a
|
||||
is all that's needed to refer to that gargantuan UUID.
|
||||
|
||||
Another example:
|
||||
!1:a()!1:a(?1:a?1:a)!1:a(?1:a?1:a)?1:a
|
||||
is equivalent to
|
||||
((()())(()()))
|
||||
|
||||
|
||||
"Having metrics around as many things as possible really helped us
|
||||
identify a difficult problem to diagnose."
|
||||
-- https://github.com/blog/767-recent-services-interruptions
|
64
server/TODO
64
server/TODO
|
@ -1,5 +1,69 @@
|
|||
## OCaml server
|
||||
|
||||
- use lazy and Lazy.force where appropriate
|
||||
|
||||
- Figure out how to avoid the overhead of Message.message_of_sexp
|
||||
- straight matching of sexps without translation gives a ~5% speedup
|
||||
- checking for "post" first in message_of_sexp gives a ~3% speedup
|
||||
|
||||
## General
|
||||
|
||||
Cope with possibility of duplicate uuid, in e.g. queue/fanout/direct.
|
||||
If a subscription token matches an existing subscription, there's a
|
||||
collision, so choose a new token until there's no collision.
|
||||
|
||||
SAX-style sexp reader/writer, so that we can do something sensible for
|
||||
enormous (e.g. gigabyte-sized) messages.
|
||||
|
||||
The "meta" exchange probably wants to be a topic exchange. Or
|
||||
something.
|
||||
|
||||
The "meta" exchange probably wants to emit how-things-are-now messages
|
||||
when people subscribe to it, to get them started; a kind of
|
||||
last-value-cache type thing.
|
||||
|
||||
Website
|
||||
- http://www.flickr.com/photos/elemishra/158211069/
|
||||
|
||||
Switch from indirect scheduling to direct scheduling
|
||||
- before, on walk: 173kHz test1/test3
|
||||
- after, no change. Probably because we only have a single thread
|
||||
active in the system when running test1/test3, so every time some
|
||||
work comes in, it baton-passes to the next guy in the chain. The
|
||||
change *would* be an improvement but we have a separate worklist
|
||||
(to process now) and runlist (to process after polling for events
|
||||
once) so it always goes back to the scheduler because the worklist
|
||||
is never longer than one.
|
||||
- Revisit once we start testing multiple concurrent streams.
|
||||
|
||||
|
||||
Extension to Sexps:
|
||||
|
||||
- ! <simplestring> <value> : binds the simplestring to the value when
|
||||
seen. Note that the new binding for simplestring is NOT in scope
|
||||
during parsing of the value, so no circular data can be constructed
|
||||
this way. Any previous binding is discarded *after* the value is
|
||||
completely read.
|
||||
|
||||
- ? <simplestring> : retrieves the bound value of the simplestring.
|
||||
|
||||
So
|
||||
!1:a11:hello world(?1:a1: ?1:a1: ?1:a)
|
||||
is equivalent to
|
||||
(11:hello world1: 11:hello world1: 11:hello world)
|
||||
|
||||
And, more to the point, after a receiver has seen
|
||||
!1:a36:af49f5dc-0454-4ba1-9f48-a55e9c10ee35
|
||||
then a simple
|
||||
?1:a
|
||||
is all that's needed to refer to that gargantuan UUID.
|
||||
|
||||
Another example:
|
||||
!1:a()!1:a(?1:a?1:a)!1:a(?1:a?1:a)?1:a
|
||||
is equivalent to
|
||||
((()())(()()))
|
||||
|
||||
|
||||
"Having metrics around as many things as possible really helped us
|
||||
identify a difficult problem to diagnose."
|
||||
-- https://github.com/blog/767-recent-services-interruptions
|
||||
|
|
Loading…
Reference in New Issue