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

content/browser/presentation/presentation_service_impl.h

 // Copyright 2015 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #ifndef CONTENT_BROWSER_PRESENTATION_PRESENTATION_SERVICE_IMPL_H_
 #define CONTENT_BROWSER_PRESENTATION_PRESENTATION_SERVICE_IMPL_H_
 
 #include <deque>
 
 #include "base/basictypes.h"
@@ skipping 145 matching lines @@
   void ListenForDefaultSessionStart(
       const DefaultSessionMojoCallback& callback) override;
   void StartSession(
       const mojo::String& presentation_url,
       const mojo::String& presentation_id,
       const NewSessionMojoCallback& callback) override;
   void JoinSession(
       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;
 
   // mojo::InterfaceImpl override.
   // Note that this is called when the RenderFrameHost is deleted.
   void OnConnectionError() override;
 
   // WebContentsObserver override.
   void DidNavigateAnyFrame(
@@ skipping 61 matching lines @@
 
   // NOTE: Weak pointers must be invalidated before all other member variables.
   base::WeakPtrFactory<PresentationServiceImpl> weak_factory_;
 
   DISALLOW_COPY_AND_ASSIGN(PresentationServiceImpl);
 };
 
 }  // namespace content
 
 #endif  // CONTENT_BROWSER_PRESENTATION_PRESENTATION_SERVICE_IMPL_H_