[PresentationAPI] Implementing send() from WebPresentationClient to the PresentationService.

content/browser/presentation/presentation_service_impl.h

Index: content/browser/presentation/presentation_service_impl.h
diff --git a/content/browser/presentation/presentation_service_impl.h b/content/browser/presentation/presentation_service_impl.h
index 104b3ae9b92b5d79fb731a844629e0e9f1f0d941..8b77320929ab99f128b0c6d8fdd25328837df7e5 100644
--- a/content/browser/presentation/presentation_service_impl.h
+++ b/content/browser/presentation/presentation_service_impl.h
@@ -163,6 +163,10 @@ class CONTENT_EXPORT PresentationServiceImpl
       const mojo::String& presentation_url,
       const mojo::String& presentation_id,
       const NewSessionMojoCallback& callback) override;
+  void PostMessages(

[mark a. foltz, 2015/04/02 20:46:26]

For all types that can be sent/received, we need to design this implementation
based on the constraints of Mojo and the desire to not allow a rogue client to
spam the browser.

For example:
- What if the data to be written exceeds the MessagePipe's incoming buffer?
- Will there be any advantage to chunking up a large write into smaller writes?
- We should acknowledge that the last message was sent onto its destination
before requesting the next message from the client (flow control)

For now we could limit the size of individual messages to something small and
reasonable (64k) while we work through the other issues.

Anton/Derek, WDYT?

[imcheng, 2015/04/02 23:57:24]

We must limit the size of the messages. 64k sounds fine.

[USE s.singapati at gmail.com, 2015/04/07 17:45:16]

Acknowledged. Do we want to stop sending messages exceeding the limit for now?
This can be done on Blink side also.
Or break them into smaller somehow and send as chunks? this might be tricky and
needs more handling.

+      const mojo::String& presentation_url,
+      const mojo::String& presentation_id,
+      mojo::Array<mojo::String> string_messages) override;

[mark a. foltz, 2015/04/02 20:46:26]

Mojo guarantees FIFO order for messages sent through a MessagePipe.

https://docs.google.com/a/chromium.org/document/d/1kvWHSHe-r7ty6wl3vhXXcSbyus...

I don't batching them is necessary to guarantee order.

[USE s.singapati at gmail.com, 2015/04/07 17:45:16]

I've created a patch with new queuing approach to discuss both approaches and
decide: https://codereview.chromium.org/1061363002/. (I will merge queue changes
in new patch into current patch based review)

In this patch simple queue is used for message requests
(std::queue<linked_ptr<MessageRequest>>) and sends one message at time, instead
of sending array of messages.

Also, current hash_map of vector implementation has below problems:
- When first message (one message in vector) is sent to presentation service and
waiting for callback, Then if some new message requests come from session and
inserted into the vector. When callback is received, the first element in the
hash_map will be deleted, thus newly inserted messages into vector will be lost.

- When a session sends different messages in order (for eg., string, array
buffer, blob, string...), it is difficult send as array of messages.

   void CloseSession(
       const mojo::String& presentation_url,
       const mojo::String& presentation_id) override;