I'm sorry for some reason I did not get any email on this!! :/
These are my opinions but feel free to ignore if not convincing ;)

> 2. The two both serve the communication between dlcservice and update_engine.
In fact, they are both communicating the same thing, its just a list of ID strings. And in concept they should be the same because install and update parameters regarding DLCs are identical.

> 1. The extra string has to be ignored for DlcModuleList and causes confusion. 
That is the purpose of protobufs. You can include or exclude items as needed. The confusion can easily be addressed by comments, etc.

> 2. More comments (multiplexing the same protobuf for 2 different API) are needed to dis-obfusticate the developers.
I don't think we should design a system based on how hard it might be to put comments for its elements.

> 3. DlcModuleList and DlcParameters serve different APIs (GetInstalled vs AttemptInstall) for different services (dlcservice vs update_engine).
IMO that is not a valid point. Just because different users use them doesn't mean they have to be separated. For example when we use shared libraries among different users, every user uses the same API interface. They don't just create their own API and implement it because it just doesn't make sense. In other words APIs need to portable enough to be used by multiple parties if possible. Imagine in future Chrome OS wanted to add a new service that lets say gets the list of DLCs and like dumps their statistics, etc. Does something with them. Do you think they should again invent the wheel and create their own API for this?

> 4. More diverges (expected but not sure atm) cause more severe 1 and 2.
Well, when that happens then we can think about it, but I don't think that would be case because as mentioned earlier both of these items carrying the same data and fulfilling the same purpose. A list of properties for DLCs to be either installed or updated. And there is technically no major difference between installing and updating them either.

> 6. Hard (or Easy) to maintain?
I argue that having one source of truth is easier to maintain. It doesn't require double changes to reflect both files.

> 7. One more *.proto file (to maintain!).

In summary, I think having one proto file reduces the cost of maintenance, is more accurately reflects the communication between these two modules, and is less error prone.

But that's just my opinion :)
Thanks

This issue has an owner, a component and a priority, but is still listed as untriaged or unconfirmed. By definition, this bug is triaged. Changing status to "assigned". Please reach out to me if you disagree with how I've done this.