I have a question about how to structure communication between a (new) Firefox extension and existing C# code.
The firefox extension will use configuration data and
Use the first if you need any sort of RPC. Otherwise, you'll find yourself writing an RPC language, validations, construction/deconstruction, etc., just a little overboard for something on a local machine.
Best option if you have a very passive plugin. The third component entirely decouples the two processes, which is great for a lot of things, including as mentioned above, async, testing, ease of implementation, etc.. Probably a silly idea if you want to do a lot of message passing.
Probably the best option overall for most things. TCP/IP is nice from the standpoint of sending stuff across the internet, but you don't really want two different IP addresses or to mess around with setting up webservers and possible port conflicts. Pipes make more sense, or some other similar serial communication model. It decouples well, it can be entirely async (TCP/IP is async, normal HTTP is not, pipes are too), its very easy to test (assuming you don't have to write any of the protocol of course), and it couldn't care less about code base. Which means tomorrow, if your C# backend turns into say, a Ruby one, or a Python one, the entire thing still 'just works'. Its better than sqlite as well, since you don't have to worry about packaging an entire library and database with your plugin.
The only downsides to the third option, is (one) that things will be async but should be responsive and active, whereas sqlite allows things to not only be mostly passive, but it isn't phased by you shutting your computer down for a week. And (two) its not amazing for RPC either, if you want to do that again you end up inventing your own protocol or dealing with something like SOAP and WSDL.