Motown in-proc streaming framework used to implement media services.

services/media/framework/result.h

+// Copyright 2016 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 SERVICES_MEDIA_FRAMEWORK_RESULT_H_
+#define SERVICES_MEDIA_FRAMEWORK_RESULT_H_
+
+#include <cstdint>
+
+namespace mojo {
+namespace media {
+
+// Abstract base class for objects that allocate buffers for packets.

[johngro, 2016/01/26 23:47:29]

cut-n-paste error, this is not the comment you are looking for <jedi_wave/>

[dalesat, 2016/01/28 18:49:16]

Good eye, thanks!

+enum class Result {

[johngro, 2016/01/26 23:47:29]

So, I did the same thing (defined a media result in .mojom) and got chewed out
by Trung and James.  Trung has a vision for an error code system that he wants
us all to use.  I had difficulty figuring out how it was going to solve my
problems, but they made me comment all of my codes with which one of Trung's
codes they would become someday.

No action requested here, but we may want to consider defining these in .mojom
so they can be used over mojom interfaces.  When we revisit, we should probably
take a second look Trung's proposal and make an effort to make use of it.

[dalesat, 2016/01/28 18:49:16]

I currently aspire to make the framework free of mojo dependencies. If we give
up on that, I'm happy to use MojoResult or MediaResult.

[johngro, 2016/02/01 22:38:16]

Ack

I'm not certain that it is possible or desirable to make the framework
completely independent of mojo.  In particular, it seems (to me at least) like
that Turquoise is supposed to be fundamentally a service oriented architecture
with all inter-service communications built out of mojo.  Because of this, all
of the components in the AV architecture must, first and foremost, be defined
using mojo interfaces and primitives.  If we end up implementing most or all of
our service implementations using this framework architecture, it seems
advantageous to have it understand, at a deep level, how the edges of the
service will communicate with other services (read; Mojo, message loops, mojom
defined interfaces, etc...)

Regardless, this is a deep design discussion; not something to do during this
review.  Let's have this discussion somewhere else.

[dalesat, 2016/02/01 23:01:28]

Acknowledged. I'll soon be uploading a CL that has all the mojo transport stuff.

+  kOk,
+  kUnknownError,
+  kInternalError,
+  kUnsupportedOperation,
+  kInvalidArgument,
+  kNotFound
+};
+
+}  // namespace media
+}  // namespace mojo
+
+#endif // SERVICES_MEDIA_FRAMEWORK_RESULT_H_