Interface Design Notes

Defects of the current design of interfaces and modules:

• Cannot import a given module twice
• Interface names aren't scoped (#49)
• Need to explicitly include Anise for the "declare" decorator (#59)
  • Easiest fix is to have a root BudModule/BudProtocol/etc. module that includes Anise and defines "declare"
• "state" blocks in an interface need to explicitly call "super"
  • Possible fix: replace "def state" with a "state { ... }"; state is a method defined by BudModule
• No clear distinction between importing a module for use as a client vs. importing an interface to provide an implementation of it
• Should temporal properties be exposed as part of an interface's API?
• Constraints on interfaces?
• What is the relationship between Bud instances and interfaces? i.e., if we expect that half of a module will be implemented at one site and half will be implemented at another (e.g., ACKs for reliable delivery), how should that be reflected in the module itself?

Use Cases for Modules

###Abstract interface, multiple concrete implementations

• Participants: client program P, abstract interface A, concrete implementations B and C
• P wants to use the functionality provided by A, but doesn't particularly care which implementation of A it uses
• Example: P is a program that wants to unicast messages to a remote host. A is an abstract DeliveryProtocol, and B and C are concrete delivery protocols (TCP-based and UDP-based, say).

###Composition of interface implementations

• Participants: abstract interface A, concrete implementations B and C.
• B implements A; C also implements A, but wants to reuse some of the machinery provided by B.
• Example: A is DeliveryProtocol, B is UnreliableDeliveryImpl, and C is ReliableDeliveryProtocol. We can implement reliable delivery on top of unreliable delivery + additional ACK messages.

###Multiple instanciation of a single module

• Participants: client program P, module A.
• P would like to use two different instances of A for different purposes
  • Q: When is this actually necessary? There are circumstances in which a single instance of a module can be used for two unrelated purposes simultaneously (e.g., a DeliveryProtocol can be used to send messages to different hosts concurrently).
  • A: The answer has something to do with whether there is shared state among different clients of a single module. Consider the case of a queue module: if we want to use the module to represent two logically-distinct queues, we can do that by adding a "queue id", and grouping on the queue ID.
  • Conclusion: (?) Multiple inclusion is not necessary for expressiveness, but might be useful syntax sugar.