As was decided during a
meeting before the hackathon (although I can't find the Google Doc
in which this decision was made), the format of requests should
allow flows to be specified by specifying a many-to-many relationship
between sources and destinations. An example is as follows:
can be compressed to the dictionary given above. But this code doesn't
currently do that. The problem of finding an optimal compression
strikes me as NP-hard (although I haven't actually thought it through).
Thus, the current code simply naively translates the input string into
a dict. We might either want to change this, or decide that compression
is unnecessary/too much work, and change the design.
As was decided during a meeting before the hackathon (although I can't find the Google Doc in which this decision was made), the format of requests should allow flows to be specified by specifying a many-to-many relationship between sources and destinations. An example is as follows:
{"srcs": ["src1", "src2", "src3"], "dsts": ["dst1", "dst2"]}
The above dict defines six flows: one flow from each source to each destination.
Now, this format was chosen to allow for the compression of requests. However, the input format groups flows by source. Thus, an input like
SRC1 -> DST1 DST2 SRC2 -> DST1 DST2 SRC3 -> DST1 DST2
can be compressed to the dictionary given above. But this code doesn't currently do that. The problem of finding an optimal compression strikes me as NP-hard (although I haven't actually thought it through). Thus, the current code simply naively translates the input string into a dict. We might either want to change this, or decide that compression is unnecessary/too much work, and change the design.