Protocol / client plugin changes to support interactively asking for a PIN

remoting/protocol/pin_fetcher.h

Index: remoting/protocol/pin_fetcher.h
diff --git a/remoting/protocol/pin_fetcher.h b/remoting/protocol/pin_fetcher.h
new file mode 100644
index 0000000000000000000000000000000000000000..c85d222ad9c236dbeb514c81976418a5734cd9b7
--- /dev/null
+++ b/remoting/protocol/pin_fetcher.h
@@ -0,0 +1,25 @@
+// Copyright 2013 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 REMOTING_PROTOCOL_PIN_FETCHER_H_
+#define REMOTING_PROTOCOL_PIN_FETCHER_H_
+
+#include "base/callback_forward.h"
+
+namespace remoting {
+namespace protocol {
+
+class PinFetcher {

[Sergey Ulanov, 2013/03/17 21:29:21]

Do we need this interface at all? There is only one method, so you can just use
base::Callback<void(const PinFetchedCallback& pin_fetched_callback)>

[rmsousa, 2013/03/18 21:07:26]

Kinda... there's also an implicit Cancel() (in the destructor). And we may also
want to add some more stuff here (like pin dialog options, etc). I think it's
worth having a low-level object corresponding to the webapp PIN dialog.

[Sergey Ulanov, 2013/03/19 02:44:53]

But what does the cancel do? Would it hide the PIN prompt (I didn't see anything
in the plugin interface for that). If it doesn't hide PIN prompt, then I don't
think we need to worry about cancellation (again you could use weak pointers for
to make sure we safely ignore pin_fetcher_callback when the handler is
destroyed.)

[rmsousa, 2013/03/19 23:14:31]

Done.

+ public:
+  typedef base::Callback<void(const std::string& pin)> PinFetchedCallback;
+
+  virtual ~PinFetcher() {}
+
+  virtual void FetchPin(const PinFetchedCallback& pin_fetched_callback) = 0;
+};
+
+}  // namespace protocol
+}  // namespace remoting
+
+#endif  // REMOTING_PROTOCOL_PIN_FETCHER_H_