Good afternoon and welcome to Camera 2.0. So before we get started, I just wanted to get a feel from the audience. How many people here work with the Camera APIs? How many people have tried to bring up a new image sensor on hardware? And so what are you looking for? What, any particular interest, somebody who's never dealt with cameras at all, anybody totally new? Excellent, so we'll try to make it so we can cover, give you a background and then go deep dive into the Camera 2.0, which is the new hardware interface layer. So before we start, welcome once again. I'm Balvinder Kaur and I work with Apptina. I've been there about a year and a half, been doing Android since 2009. I was at T-Mobile before that. I have a lot of background in mobile software and apps, but not so much as camera until I came to Apptina. And I used to really think that, oh, it's this tiny little thing and it takes a picture, but I'm quite amazed at everything that goes into it and how complex it is. And we have, so Apptina builds image sensors. We have our image coprocessor and we also have our Android camera stack. And some of the things we're talking are experiences based on bringing up our own sensors. And I have Ashutosh who's flown in from India just to be here with us today. Hello, Grafton, everybody. Welcome again for this talk. I am Ashutosh working with, so I'm working with Apptina and Android for the last three years. And prior to that I was at Samsung Electronics and I worked on a range of multimedia devices over there. So yes, we will be talking about Camera 2.0. Thanks, Ashutosh. Okay, so our agenda today will generally talk about the camera use cases since it's an embedded Android summit. We're not going to focus too much on the API part of it and the SDK part of it. But we'll go briefly over what the different classes are and what's available to an application developer. Focus a little bit about on the camera surveys. Now with Jelly Bean 4.2, the camera service got re-architected in a big way. There are still no implications at the application layer or the APIs that are available. But we will talk about what the new architecture is. After that, I'll hand it over to Ashutosh and he's going to cover everything that's below the hal. So what's the new interface? The architecture of the Camera 2.0 hal. What does it look like? Device drivers. And then we'll talk about some of the challenges that typically whenever we bring up a new image sensor on a new platform are things we run into. Lastly, we'll talk about some of the emerging trends in this industry and where we think the future is going to be. Hopefully we'll have time left for Q&A at the end. So what are the prominent use cases? Very simply, once you have a camera and a device, you need to be able to do a live preview. So whatever you see, a viewfinder basically. Sometimes not only do you need the view, you also need to be able to provide. That typically goes right from the image sensor to the display subsystem. It doesn't go back up to the application developer. But sometimes developers want to do things with it. So a copy of the preview frame back up to the application developer. Then we have the ability to capture a frame. That's what the most common use case of an image sensor is. I'll talk about a little bit about the emerging field of computer embedded computer vision where image sensors are not necessarily used for getting images but also as a means of getting information especially for the context aware phones. Finally we have video recording of a camera stream. Then there are other secondary use cases. Basically at this point everything, think of a point and shoot camera are a little bit more controlled. What are the different scenes available? Can I set the scene? Is it a sports scene? Is it a night scene? Can I put any filters on it? The new feature that came out with Ice Cream Sandwich was the ability to take a snapshot during video recording. Finally we have the different even callbacks. The shutter was clicked. If the application developer wants to do something special at that time they should be able to do it. Focus was achieved. So these are the different callbacks that the camera subsystem provides to the application developer.  As of today there are very few classes and very few very little metadata that is provided to the application developer. The most common is the face class which will tell you how many faces were detected in the scene. What is the confidence level that it is a face? What is the location of the eyes? What is the location of the smile? So metadata of an image. But like I said it's very limited. With 4.2 there's a lot of plumbing that has been done and a lot of emphasis on being able to provide metadata right up to the application layer. There are limitations with this camera API. So if you have any of the Android phones, the HTC, Samsung you'll see that their camera applications can do a lot of features which there are no APIs for it. For example burst mode photography which is very common. You could have continuous burst where you start the shutter button and it keeps taking pictures till you release it. Or you can have a time you take a shutter and it takes three bursts in succession. There's no support for panoramic shots. Then there's no frame data like if there's no frame metadata that is available. If I want to know that there's a frame a frame was taken but what was the exposure with it? What was the focus with it? There's none of that information is available right now. There's no power frame control of the camera. So to back this up a little bit this whole thing about camera 2.0 there's a lot of research that was done at Stanford and you can search for fcam or camera 2.0 and there they describe a lot of the use cases of what they would like to do with the camera. Our example HDR which is high dynamic range. So many times I'm sure you've taken pictures where something is in the shade and it's unclear and then there's sunlight and something under a tree and that's not clear. So high dynamic range what they do is they take multiple shots at different exposures and then they stitch them together. Same thing with flash and no flash. You could have a scene for example a person is sitting in the dark and there's lights outside. You want the flash to be on the person but you also want those lights at the back. So the ability to combine flash and no flash together. There are multiple range of applications that can only be achieved with power frame control. See for this frame I want the exposure to be this, I want the gain to be this. Then there are other things whatever you get back from the camera subsystem is three callbacks. You can get what is called post view callback, there's a JPEG callback and a raw callback. I haven't still seen any device where you can actually get raw callback. I could be mistaken but I haven't seen one so it's not very common. JPEG is the one that is common but you can do a lot of things if you get the raw information from an image sensor. So all of these things are still missing. And now just to give a little bit of overview of what APIs we have currently, there are six classes. Out of this the most interesting ones are camera and camera dot parameters. There are eight callback interfaces and the one at the bottom is in yellow because it was the latest one introduced with 4.2, the rest are all 4.1 and previous. So out of this camera gives the capability to open a camera, close a camera, have access to the camera controls, you set up a preview and of course you can take a picture. The camera parameters class is a huge class with a lot of different API methods. So to help understand with this, there are three categories of API, most of the APIs will fall in. Some of them is the mandatory feature set which is have, which are typically named like get supported preview size, get preview supported preview formats. They have the supported. That means every camera on Android subsystem needs to provide certain mandatory features. There are gets and sets for those. Then there is the optional feature set. Things like is video stabilization available. Now just because there are APIs available doesn't necessarily mean that the whole stack is functional. You could have hardware that doesn't support it. You could have hardware that supports it but maybe you haven't done the correct plumbing in the camera hal and it's not available to the end user. So these are runtime calls. And typically an application developer would do at runtime and say is this feature supported and if it is then you can go and enable whatever you want to do from the UI perspective. Finally, there's also a dump pipe that is available. And we use this a lot internally to provide our own features. For example, I mentioned that burst is not available but we have our own burst extension. There are other things that are not available which we provide. And so we use this dump pipe and basically it's just providing string parameters. You can query the system for what string is available but it's very OEM dependent. Somebody really has to know that the implementation of the camera hal. It will not be a generic solution. And then the rest of the camera classes which I already mentioned briefly earlier. Now moving on to the camera two internals. These got released as so one of the first big disclaimers I would like as we move into this section is that the only documentation that we have is actually reading all the Android open source code and picking up things from trying to figure out what the design is, trying to look at what the method names are, the comments that are there. So one it's all, so you have to, there's no document which kind of defines all of this. So that's one thing to be cautious of. Second is right now there is no APIs available at the SDK. So the next version of Android could very well go and change some of these. So just something to be cautious of in case you're gonna go back and refer to this part. Now this was when I first started when 4.2 got released and I started looking at it. I saw all these references to camera two, there was a camera two dot age, there was a lot of classes and then I started wondering which application was using it. But turns out there is no application that is using these features as of now. Not even the closed source photo sphere that was released, the Google app that was released with 4.2. The HAL implementation that came, that was open stored was the Samsung Xinus 5 based and we'll talk about it later during the talk. And this reference to Android or hardware or pro camera actually came from one of the comments there, which kind of indicated that that's what they're trying to do with camera two. Is provide very fine grained control. So very briefly, I'll go over, I'm sure everybody here in this room has seen this cake diagram. So I'll be focusing on the camera HAL and where it sits. So it's that little piece in the hardware abstraction layer. And it comes with its definition and we and all other OEMs provide their own implementation based on the application processor. That's the camera subsystem. The top part, as you can see, is hardware independent. The bottom is very closely related to the hardware and the hardware in which this case mostly involves the application processor, the image processor, co-processor and the camera hardware or the image sensor itself. So, just the process view. The camera service resides within the media service. Whenever there's a new application, it requests, it makes a request to access a camera over the binder interface. And if it has all the permissions, then the camera service will grant it permission. And it does this by creating a camera hardware object, which then makes system calls into the kernel to actually communicate with the hardware. There's also a communication path from the image sensor to the surface flinger or the display system for preview purposes. If there is a second application and it wants access to another camera object, that is typically granted. However, at a given time, only one application can have access to one camera and a given camera can be accessed by only one. So as a good, from the application development perspective, to be a good citizen, whenever you get into the past state, you should release all your handles to the camera. Inside the camera application, the only thing that's interesting here is what's below the GNI. And this basically, the thing that hasn't changed between camera one and camera two is that any frame, any frame information, there is always a copy made from the native to the application space. And I think it's almost like a security thing here. You wouldn't want, for one of the use cases is a burst, right? Let's say we have an 8 meg sensor and we want to take two seconds of burst. Now, this becomes a problem then, right? Because if for 8 meg picture, let's say you compress it and you have like a 2 meg JPEG, you have to make copies if you want to return it to the application. And if it's running at 30 frames a second, it's a huge problem. There's a lot of memory copies doing away. So this again highlights one of the limitations that are there. I still haven't seen within the re-architecture or solution to this problem. But maybe with the next version of Android, something does come up. It also holds references to different objects and the callbacks are made using the JNI layer. So now moving on to camera service. So everything in the middle are the eye binder interfaces. The camera service is the libcameraservice.so. Camera.h is the hardware interface, which whoever's providing the camera how will implement. Now this changes with 4.2. What we have here is that the libcamera service can now talk to two different interfaces, camera.h and camera2.h. And a given device can have implementations of camera edge or camera2.h. Now there is some glue classes that were discovered, which is camera2client and camera2device, which basically enables this libcamera service to talk both to camera.h and camera2.h. Now let's try to understand a little bit more about what is this difference between the two. So this one I think I've covered. It's basically what does the camera service do? So one of the basic differences that happened between camera1 and camera2 was that in camera1 everything was a function-based. The whole view of the image sensor and the camera subsystem was function-based. Take a picture, get the preview, set mode, and things like this. That has changed from an entirely streaming perspective. So there are different streams that are available at any given time. There's the preview stream, there's a capture stream, there's a callback stream. The ZSL stands for zero shutter lag. There's a recording stream, and it's all stream-based. So there's a steady stream of information that is available from the sensor. So it becomes more dynamic. You can insert different things, you can access different things, you can reprocess them. The camera2.h client sits on top of the HAL and it has different processors that run. These are the different processes they talk to different streams. And Ashutosh will go over this in more detail when we start talking about the camera HAL implementation. The other thing is there's a big focus on metadata now. Metadata of two kinds, static metadata, what are the capabilities of this camera? You don't have to open the, you don't have to open an instance of the camera to actually get that information. It can be, the system can be queried statically. The other is there is now an attempt to minimize copies. Because see out of all the sensors that are available on a device compared to the accelerometer or the gyrometer, the most memory intensive sensor is the camera. And so there's an attempt to minimize the copies between within the native subsystem. The one that happens from native to application for the Dalvik virtual machine, that still exists. But within it, there is an attempt to minimize the number of memory copies. Metadata, there's two kinds of metadata, static and frame-based. The ones where, and if you open up the file, I have all the links at the end in a couple of slides. It has the path to where you can open up the file and actually see. It has a whole list of tags. So the ones that are marked with underscore info are the static ones. The ones that don't have it, typically you'll find Android Flash and Android Flash Info. The others are frame-based. So this frame, when it was taken, what was the flash setting? And it comes bundled back with the frame information. And for all the OEMs in the room, there is provision to provide vendor-specific tags. So if you want to do something to differentiate your stack, this is available. So earlier, just like the camera parameters pipe was available, is available to do settings to control the image sensor. The vendor-specific tags is, again, is another provision, a dumb provision, to be able to actually provide metadata back to the application layer. So now it's become like a two-way street instead of one way. These are all the directories. The only thing I have is the AV highlighted in yellow, which is where the paths change from ice cream sandwich to jelly bean. And the metadata that I was mentioning is the last line on the slide. So are there any questions? Sure. I will be emailing them right after the, yes, sure. And feel free to get my contact information and we can communicate if there's any other information you would like in the future. So that I'd like to hand it over to Ashutosh. Thanks. Hello. Hi. Good afternoon to everybody. So I will be talking about the camera HAL in particular and all the layers that are underneath it. So basically it is, it comprises of camera drivers, different configurations for the drivers, and then we will see some of the challenges that you will face while building up your hand. So this is the typical camera stack in the Android framework. Must have seen it some time. So basically this block is what is known as the camera HAL, hardware special layer. So every vendor has their own implementation of the of this abstraction layer, which basically depends upon the underlying hardware, the kind of SOCs which they are using and the kind of camera hardware they are using. So we will be first talking about the changes which is undergone from ICS to JB, and then we'll move to the camera driver. So this is the typical functionality of the camera HAL, the camera hardware abstraction layer, it basically is very specific. As I have already told you, it is very specific to the camera hardware platform and basically implemented by the vendors. So every vendor has their own proprietary HAL which provides, it basically maps the service calls which is mandatory by the Google to the driver functions. It will get the functionality out of the driver. So Ice Cream Sandwich uses camera.h and Jelly Bean and above probably the next versions of Jelly Bean will use camera 2.h. And the camera HAL also talks to the camera driver. So basically there can be multiple flavors of driver available. Some of the most popular ones are V4L2 and OpenMax. And on top of that, vendors can have their own proprietary implementations of the driver just to, just in case they don't want to expose the functionality. Excuse me. It communicates with the driver through the file IO calls. So this is standard Linux IO calls that they use to talk to the camera device. So this is the functional camera HAL diagram that's how the camera HAL used to look like till ICS and the previous versions. So if you see that the major functionalities of the camera HAL is to manage the memory, it should know what kind of memory it is dealing with, what kind of, what kind of memory the camera hardware needs from it. Then it needs to manage the display surface in a way that the ultimate consumer for the camera buffers are the display surfaces. So it has to manage the equilibrium between the display and the camera. It basically needs to respond to the events that it is getting from the driver and it also needs to generate the event for the application layer. And ultimately it has to manage the camera. So basically this is the camera manager which talks to the camera driver. And this is how it looks into the jelly, this is how it looks with jelly bean. So if you have seen as my, as Balminder has already talked about it, previously the HAL was more function based. So the aim was to get a certain kind of stream. If you want to get a preview, you say start preview. If you want to take an image capture, you do take picture and all this thing. But now going forward the jelly bean onwards, they are not viewing it as a piece of camera. They are viewing it as a stream. So basically the stream can be of multiple types. There can be preview stream, capture stream and capture stream, positive stream, metadata stream and potentially all of them running together at the same time. Metadata as she has already mentioned in her presentation that nowadays focus is much more on metadata. It is the information, extra information associated with the image which basically typically opens up the new horizon for creating some cool apps. So some of the typical metadata are like if you have face information, if you have some interest point information that you want to give out, give it out it can be stream specific or it can be camera specific which can differ. The third thing which I think they have introduced is the reprocessing of the stream. So whatever the initial two block which we talked about deals with the live camera stream which is coming out of the sensor. Here in the case of reprocess stream, we are talking about the stream that is in your memory that you just want to give it out for the reprocessing to do some other processing actually. And the stream manager is the guy who will talk to the camera driver here. So basically stream manager job is to manage the buffers what kind of memory it requires and how it will get the frames out of the camera driver. So this is the guy who will be responsible of talking to the camera driver. So this is just to understand the functional and just to see who does what. So camera HAL basically initializes all the different blocks which we have talked about the stream manager and all of the guys. Basically dispatches all the function calls which it gets from the camera service to the respective blocks. Then the stream manager is the one who basically handles the streaming events who gets its own buffers who manages its own memory and it talks to the camera hardware and also manages the state machine right from stream on to the stream off. Then metadata handler the job of the metadata handler is acquire per short metadata, get some interest points or other things that is required and convert them to the android format and plumb it back and give it to the application layer. Reprocess stream manager basically it sets up and manages the reprocess streams. So this is pretty much about the functionality. Changes, what are the changes that has taken place since camera HAL 1.0. So if you see most of the camera HAL 1.0 functionality has been moved to the service, live camera service. You see the camera to device and all these things have been moved to the camera service. Image metadata has got more importance. So basically there is a different handler that is created specifically to get the metadata to open up the new horizons to create multiple applications. Reprocessing introduced, process and already captured image stream. Then as I have told you before this new HAL is based on the streaming it basically generalized the stream rather than on the function basis. So the camera HAL 1.0 used to have start preview, take picture kind of functions whereas in the camera HAL 2.0 you will see that allocate stream, start streaming and stop streaming kind of the functions. And every stream can, I mean one of the stream can be preview stream, capture stream and some of them or all of them may be running together. So this is again the same diagram. So this is about the camera HAL changes, what all the changes have been taking place from the camera HAL 1.0 to 2.0. Now I will be talking about the driver, some of the popular implementations of the driver and then we will see the challenges. What the driver offers to the upper layer basically? So as you see that there are multiple companies that are involved in this camera hardware creating that image sensor and all other things. So basically the camera driver represents a standardized interface for the HAL and the above layers to access the camera hardware. The image specific or camera hardware specific attributes are handled at the lower layer of the driver. So the driver has two parts, one is very generalized and basically exposed API to the top layer and there is one which is very very specific to the image hardware. That takes care of the actual camera hardware. So right now there are multiple types of sensors available, some of them are raw sensors which will give out the bare image which needs to be processed through the ISP. Now ISP models are very interesting. ISPs are offered by OEMs, the platform vendors or there are some smart sensors which have the ISP on the chip. So you get all the processed image and you don't require the platform ISP which is available with the application processor. So this difference is basically handled at the driver level, whether you want to bypass the ISP or you want to use the ISP for processing the bare image and get the YUV image or something out of your system. For Android, VG4 Linux 2 is used in many implementations. It has been in existence for many years and I mean recently it is undergoing some changes to accommodate the new interest and to accommodate the finer control over the hardware blocks as the hardware is getting more complex. OpenMax is another one which is getting popular and it also is being used to control the camera hardware. This is the V4L2 kernel level block diagram. So if you see what it offers to the top layer is basically a generalized way to access the device and supports Ioptal dispatch and this is the controlling interface for the V4L2. It basically controls the buffer management and it also controls the camera hardware. So when we talk about the buffer management control, what it does is it depends upon the camera hardware requirement. It either allocates the memory, what is the physically contiguous memory if that is required by your camera. It manages the buffer and so basically the buffer, so you create a buffer pool and you will be reusing the pools. You will fill the buffer, then you will give it to the HAL for processing. Once HAL is done with that, then HAL can queue it back to your driver. So we call this as a QDQ mechanism. So it maintains that, it maintains the various states of the buffer. The buffer needs to go to multiple stages before it is ready for the consumption. Apart from that, it also manages the camera hardware. So basically it has the infrastructure to do the device discovery as it has been done for most of the Linux devices, device initialization. Then it talks to the device through the I2C to get device-specific parameters and if you want to do some specialized settings for some specialized registers, then it also takes care of the power management. So basically when you switch off it, switch off the power, it basically takes the sensor into the low-power states, some of them stand-by modes or complete power of the state based on your design. Then it also enable and disable image streaming, which helps you to get the streaming out of the camera. Some of the resources, some of the important resources which V4L2 has on any camera driver for that matter has. So basically memory, as I have told you, memory can either be located at the driver level if you are in the need of physical contiguous memory or there are some of the intelligent hardware that are present now which basically avoids you to use the physically contiguous memory because it is very expensive. So it depends upon the kind of hardware that you are using. Then it needs to support for the interrupts. It needs to handle interrupts such as frame and interrupt and autofocus interrupt or frame start or frame finish. There are a number of interrupts. You can choose what interrupts you want to service. Some of them which is very essential is frame finish, where your frame is ready for the consumption, and your focus events, at what stage of focusing you are at and whether you have completed the focus or not. Camera hardware control. So normally the camera hardware is connected on the peripheral buses such as I2C and SPI. So I2C is the most popular one. Still it is being used to control the maximum number of camera hardware. SPI is the faster alternative to it. And there are GPIOs again. GPIOs are basically used to connect the reset pins and all other standby interfaces for the camera hardware. Then it manages the sensor power. Sensor power as I have told you, that right now power management and peripherals power is of utmost importance in any handle devices. So basically it supports, based on the device uses, it puts the device into the low power mode and ultra low power modes whenever it is desired. This talks more about the buffer management. So in the Linux, in the V4L2, one or more buffers are supported. As I have told you, the buffers either can be allocated in the driver space or based on the hardware, you can use the buffers that are allocated in the user space also. Buffers are queued in the circular list. So you will be reusing the buffers. So basically the starting of the streaming and ending of the streaming are the ones which basically starts the process of filling the buffers. We call stream on. The buffers which is at the top of the circular queue is being taken out and is being filled with the camera data and camera HL, once it is filled, camera HL de-queues it. It crosses the buffer and it queues the buffer back again to the driver so the buffer becomes available again for acquiring the data.  It basically stops the streaming and it releases all the buffers that it is holding right now. So this is just the call sequence of what are the calls that you have to follow in the V4L2 framework to get the preview out. Some of them are mandatory, some of them are optional. So I guess let's just concentrate on some of the ones which is important. So first thing is set format. So here you set the image format and the size. Here you say that what kind of color format that you are dealing with and what will be the frame sizes. And I guess cropping, if you want to set the cropping, if you want to crop the image, then you just set the crop parameters or it is optional, you can just leave it out. Then you do the request buffers. You need to tell the V4L2 how many buffers you will be using and V4L2, you have to set what kind of video memory is available to the driver. Based on it, it will say whether your request can be completed or not. So request buffer you have to do, this is mandatory. Suppose the buffers are allocated in the kernel space in the driver, then you want to get the buffer attributes into the user space for your programming, then you need to do query buff. So query buff will return you the buffer characteristics. And since the buffers are allocated in the kernel, you definitely want to map them to be able to use them in the user space. So that's why you do a map here. And finally, once you get all the buffer details and everything, you need to queue them explicitly to the driver. So you say video buff, video IC queue buff. And once you have queued all of them, then you will start, you will do stream on. Finally, stream on will basically start the streaming process. It will enable the RX, it will enable the RX actually.  It will just stream, it will stop the streaming and it will deallocate all the buffers, which it has. Okay, so as I have told you that, so this v4l2 framework is quite old. It has, basically it is, I guess it is 8 to 9 years old. And initially when it was built, the camera was only supposed to do preview and some of the captures. But today camera is basically, you know, camera is supposed to do much more than just viewfinder and just image capturing. And moreover, the imaging hardware, the ISPs are getting more and more smarter. There are more and more IPs are getting added to it. And to get the maximum out of the camera, the users are demanding finer control because there are multiple paths that can be available. You can decide which paths you want your data to pass through for processing to get the desired use case done. So keeping this in mind, I think they are the v4l2 community. Basically they are coming up with this media. They have come up with this media controller architecture. So it is designed to support dynamically reconnectable hardware blocks. Connection should be there in the hardware. So there can be a situation where one block can get inputs from multiple sources that can output to multiple sources. So it will help you in creating your own pipeline with a particular source and with a particular sync. It allows for greater programmer control. It introduces the notion of entities, paths and links. So basically your hardware block is the entity here and whatever you are seeing is the paths. So paths are the way through which the entity talks to the outer world. So there can be input paths and there can be output paths. Based on the devices it can get connected to or it is connected to in the hardware. You have those many number of paths but in the given pipeline you have only one input and one output path actor. So this is just an example what I have taken and it has been taken from OMAP3 ISP which is pretty similar, simple one. So if you see that this is the sensor MT9P031 sensor and the sensor is being enumerated as an entity and it has got a source pad attached to it. The CCDC is the parallel interface, parallel image interface of OMAP3. So the sensor is connected to the OMAP3, to the parallel interface. So if you see that the sensor has the source pad and the CCDC has the sync pad. So the data that is coming out of the sensor is going to the CCDC. Now there is a choice you can make. So suppose if you do not want to do any processing, if you do not want to do anything then you can control, you can program your pipeline for the data to flow from the sensor to the CCDC and this is a video zero note that is nothing but your memory. So directly to the memory. This is one of the configurations that you can program. Now suppose if you want to do resizing or you want to do other stuff, there are a lot of stuff I have just taken, one resizer block is an example. Suppose if you want to do, if you want to resize also then you can choose this alternate path where CCDC, this thing will act as a source pad, it will feed to the resizer and the resizer output will finally get into the memory. So like this, there is a term known as entity graph. So user will have the entity graphs where you can have the connections of the blocks possible based on the use cases. So for the bus mode photography you want one way, for the other shots you want other way. So it all depends upon the use cases but it gives the final control.  I think the first and foremost is the memory management. Since the camera HL is the one who will be talking to the driver and will be basically getting the buffers and giving it to the display for the consumption. So it should be aware of the kind of memory the camera requires and the display requires and suppose if there is no match then it needs to do copy or something like that. So camera HL, when you are writing the camera HL you should be aware of what kind of memory your camera hardware requires and what kind of memory your platform requires. Various implementations of camera driver. So as we have already discussed before L2 is one of the implementation by which you can have your camera driver implemented. OpenMax is another one and some of the vendors have their own proprietary ones. And this gains an importance because in the scenario of multiple cameras front and back one of them can get implemented by before L2 another one you can use the proprietary one or you can use the OpenMax one. So camera HL needs to be aware of that. Color format conversion. There can be multiple color format. The sensor can give out different color format. Display may expect the another one. So camera HL may need to do the color conversion either using the hardware block or the software block. Buffer synchronization. As I have told you the ultimate consumer of the camera buffers is the display surface. And so normally the buffers are shared just to save the memory so camera HL needs to manage the buffers in a synchronized manner to avoid overrun and underrun of the buffers. Then support for advanced features. The basic camera HL with what the Android offers will support only the bare minimum features. If you want to have some kind of differentiating features then you got to support it in your camera either by the Android extension or you implement the whole interface. So are all camera HLs equal? The answer is no. And in what way it differs? So basically supported features depend on the hardware capabilities. I mean the lot of functional that can be enabled only if your hardware supports it. Then also the way you implement it in the camera HL there may be a need to integrate third-party IPs to get the functionality done. So it all depends how you program it and how you use it in your camera HL. Again reliability and finally how easily you can add extensions to the Android feature set to get your other features done. I think with this I think that's all I have to talk about and probably Balminder will talk about some of the latest trends in the camera thing and probably then we'll take some questions. I guess we're running out of time. Yeah, so we have a little bit of time but we did cover most of the time. We did cover most of what we're seeing. So some of the things computer vision applications we're finding a lot of interest, object tracking, gesture recognition, augmented reality, computational photography where people can do things. I mentioned HDR, flash, no flash, different hyper focus, lots of different things. So basically the output there will be even better image quality on devices. 3D imaging is another thing that sometimes gains a lot of interest and ways I've seen things there but where you use multiple cameras to create a 3D image. And yes, so I did mention this. This was something that I found this morning where the VP of Google Wiggandotra mentioned at Google Plus last night that beware of the next Nexus will have a very insanely great camera just you wait and see. But what does it mean? I guess we'll just wait and see because that's what as much information as I have. And we're ready to take any questions that you may have.


Next question is from Jilly Bean, 390, how often would you have to mix up cardio for your body not to adapt? Or does your body consider it all the same over time? You know, my answer to this depends on whether or not you only do cardio or you do resistance training as the foundation of your workout. If you just do cardio, then it is important to switch different cardio modalities to avoid overuse injuries or imbalances. Because each form of cardiovascular activity involves some kind of repetitive motion over and over again that looks the same. So if you're biking, you're in a biking position and your legs are moving the same after every single time you do a cycle on your bike. Or if you're running or you're doing a stair master or a rower, the form looks the same and you're doing thousands and thousands of reps building endurance. And that can develop or it can lead to the development of imbalances and overuse injuries. And so whenever they've done studies on athletes, on endurance athletes, cross training helps prevent that. Because then what happens is you're still training stamina, but you're training different movement patterns. So if you go from like running to rowing, you're using different recruitment patterns for each movement and you're less likely to develop imbalances. If the cornerstone of your workout is resistance training, because remember resistance training, if you do it right, you're training the whole body. You're training all movements. You're making the whole body strong. It doesn't really matter. Now it doesn't really matter. Now your form of cardio, you can choose whatever it is, keep doing it. As far as adapting is concerned in terms of calorie burn, you can make an argument, but I think we're splitting hairs when we get there. Well, there's actually studies around this that I remember reading long time ago, but it was very interesting to me. And if I recall, it was like the average person adapts to whatever cardio modality they're doing within about two weeks. It doesn't take very long for the body to get very—adapt doesn't mean all of a sudden you stop burning calories. It just means it gets very efficient at whatever you're doing. Changing up the type, like from running to Stairmaster to swimming to rowing to rope type exercises will help, but overall your cardio endurance is going to improve in all of those and therefore the body will adapt and get good at it. So this is another reason why I always make for the case for cardio to be the last thing that we start to add into a routine if we're using it to lose body fat. If you're doing it for heart health, it doesn't matter. You want to adapt. You want to be good at it. You want to have a strong heart. You want to be good at doing cardio, but if you're doing it for fat loss reasons, the body gets used to it and becomes very efficient at it really quick.  I want to manipulate my training routine and my food first and use all the tools in my tool belt to get this person to change their physique. And then at the very end of where we're peaking, when we're almost to their ultimate physique or to their goal, I throw in cardio the last two to four weeks tops because of this reason, because the body will get so efficient at it. And then the only place to go is to just keep adding more time. And that's just an unrealistic place for most people to keep going. Like, if you've been doing—if you started a fat loss routine for eight weeks, let's say, and you right away introduced cardio one hour a day, that first two weeks or so, you're going to see the initial results from that. And then the other six weeks, you're not going to see much movement from that cardio. And even if you're switching up all the different modalities, you're not going to see it move the needle very much. Then the only thing that you can do in that world to really start to see the movement is to add more time. And then you're at an hour and a half and two hours, and that's just ridiculous for most people to maintain that for the rest of their life. Yeah, I've been trying to think of, from an athletic perspective, I would take some athletes and we would experiment and go through phases of different types of cardio. One, we would focus more on elevation. So we'd do hill sprints, for instance, versus on a level playing field. And then sometimes we do it for timed bouts where it would go, we try and simulate the time and the length of the game play that would actually occur. And so just to get them up in terms of being able to have the durability and endurance to compete at the highest level in their respective sports. So there's ways to manipulate cardio and make them applicable towards a specific goal you have if it's sports related for sure. In terms of fat loss and all that, what the guys have already said is pretty much on point. Yeah, when Adam refers to efficiency, your body also aims at getting efficient when you lift weights. It just becomes efficient at getting stronger, the side effect of which is burning more calories. When your body gets efficient with cardio, it actually learns to burn less calories because your body getting better at cardio means it doesn't need much strength because it's endurance-based and it's trying to conserve the amount of calories you burn while you're doing it because cardio is such a calorie-intensive endeavor. With resistance training, the main signal you're sending is to get stronger. So your body still gets efficient, it's just the efficiency is let's get these muscles to be able to lift this weight better and easier, a.k.a. get stronger, side effect of which being more calorie burn. But yeah, if all you do is cardio and you're an endurance athlete, well, number one, I'd say you should probably do some resistance training to offset some of the overuse stuff that you're doing. But if you don't want to do that and you just want to do cardio, yeah, mixing it up will help prevent some of that. It'll help you prevent your risk of injury and help you maintain your training intensity. If the cornerstone of your routine is resistance training, there really isn't that big of a need to mix up your cardio.


Hello, plenty of people joining in Liz. This one is yours. So yes, slides seem to be sharing just fine this morning. I know zoom has been having some challenges because reasons. But here fingers crossed. Yeah, give people a couple more minutes to join. I've just seen a couple more minutes to join. Yeah. Because it shams just the email that he's got power outage. So I'll be joining. And you'll keep track of who is with us, right? Running through the list right now. I see Schengen line. I see Brian Grant. I see just in court. Matt. Matt Klein. Brendan, I believe I see you as well. I think by the silence that yes, you're here. Yes, I'm here. Lovely. I wasn't sure. I wasn't sure if it was, you know, But when you don't put the last name in here, it's a little charred. You know, there could be a lot of Brendan. Okay. Sorry. Yeah. Let's just auto fill. Sorry. This is being Brendan. Why was asking all good. And we have Dan right as well. We do. I guess we could, we could get started with the sort of preliminaries. Maybe you can just step through those initial slides about anti trust. We all made it to the conference for Ray. We'll update those. And yeah, so in the last sort of week or two, there's obviously been a lot of. Activity around projects like operator framework and the, the new proposed projects currently called CNCF hub. And it felt to me that it would be appropriate for us to just sort of step back a bit and think about the strategy. For artifact discovery and distribution. So the individual projects. We'll have marriage that we'll want to debate and discuss, but I think we should also just step back a bit further than looking at the individual projects and think about how we want to best serve particularly our end user community. In terms of being able to find and obtain these different artifacts. And yeah, so. I think there's another slide. There's like a header that says the same thing. And then I thought maybe it would be a good idea if Dan just spent a few minutes. Discussing what he had been, well, discussing the project currently known as CNCF hub. Dan, do you want to say a bit about that? Sure. Before we step back, I think I would be appropriate for me to start with an apology where there has been a lot of Sturm and Drong about this, but some of it is quite deserted where CNCF should be operating in the open and was not in this case. The context is that I had organized a meeting in a Kubecon San Diego of some folks from operator framework and helm and Kudo to talk about the idea of CNCF, helping to organize a hub. And I'll just say all of those groups were open to it. There was no, I didn't ask for commitment and they weren't making one. And when I had the opportunity to work with a couple of well respected contract developers and was able to rely on a spec from Matt Farina of the helm maintainer, I kicked that off and the goal was for it to go for about a month and then to make it public. Essentially that got delayed by like another month, a month and a half because of all the issues around Kubecon and needing to delay that. And so that has been problematic. I do want to apologize for it. I have caused a lot of hassle for people, which I did not attend. So the aspiration was to create a project that could become a sandbox project of CNCF. I would emphasize that it's not. I also would propose a name change where I think assuming it is a sandbox project, it's assuming it could become a sandbox project and then emphasizing that this is pre-alpha code. This is not remotely production ready and won't be for many more months and particularly because I believe there's going to be high expectations on it in terms of organizations relying on it and not wanting to break the build that it would be useful to not use a term connected with CNCF. And so I would just go ahead and propose renaming it to artifact hub to also add more neutrality to that piece of it. And if there's not objections, I can go ahead and do that later today. But the aspiration here was to pull in contributors from different CNCF communities that create and distribute artifacts. And the idea is that there's certainly differences between those communities and in terms of the artifacts that they produce, but then there are a ton of commonalities. And I think we can see in something like NPM, which folks probably saw got acquired by GitHub this week, that huge industries like all front-end software in the world seems to often rely on, wind up relying on these kinds of platforms. And then there's a lot of security and reliability and maintainability and updateability and left pad and all sorts of issues that can result from it. And so I do want to emphasize that this is now totally in the open that assuming it does go forward, we very much would like to get contributions from a lot of different folks. And then that our hope would be that it would become a CNCF-hosted project that would have a set of maintainers and work with presumably, presumably SIGAP delivery and then critically would ultimately have an appeal up to the TUC because I think one of the key ideas is a piece of neutrality around it that folks understand they could deal with and such. So that is the background. These links have essentially all the information that's there, the entire repo is open and everything. And so I'll stop there. Hey, Dan, could you explain, is this a piece of software or is it a DevStats like service? Yeah, that's really sharing a decision of the TUC. And I think there was some confusion on that early on. I mean, so CMC has created several pieces of software like DevStats that we offer as a service to our projects and the interactive landscape. And I mean, we have like this minor thing we're working on right now that's going to take a YAML file and a GitHub repo and convert it to a Google calendar entries so that people can automatically schedule and cancel the conferences and such. This seems like a much bigger piece than that. But I think that one of the purposes of this call is for the TUC to decide what it should be when it grows up. But I would just emphasize right now it's nothing. I mean, it's just pre-alpha software. But I think we can have a discussion about it assuming that it did mature. It's a question from Matt in the chat asking, should the architecture and design be shared? Matt, I have a link to it. That's spec linked on the page. Is the document you wrote? Yeah, I'm just not assuming that people have read it and will understand the gist of it. And that's the reason I asked the question of it. Should a quick summary of it be shared here? And I know because people have asked me about it this week because they didn't read it. Matt, can you maybe give two minutes then? Sure. I mean, the gist is when you look at something like NPM or Docker Hub, they are hosts for the artifacts themselves where they're actually uploaded, stored and managed at that location. This isn't that. It is a centralized metadata store for search. And so if you look at what Helm has is the example because it's what's in there now, you have repositories that are hosted in many different places. In fact, anything that conforms to a repository can host it. And so people use the static built-in one that comes with Helm or Chart Museum or JFrog offers this ability. And vendors can host these things themselves. And then this provides a central point where you can register your thing. And then its metadata is pulled in so you can search it. But anytime you get the artifacts or you deal with it, it always goes back to the root source. And so it's more like a metadata search. I think PHP has something like this with packages where they don't host the packages. They're hosted in GitHub and in other places. But it provides a central discovery point for things that are distributed all over the place. And that's how the design is currently built. So it's not meant to take away from vendors hosting artifacts, but provides the ability for end users to be able to easily discover artifacts that are distributed all over the place. Oh, Matt, that does make a lot of sense because I kind of always thought this was more like Helm Hub, which was monocular and kind of I think I was a little confused. It was basically a running instance of monocular. But if it's basically a search engine for artifacts, what in the design have you, what thoughts do you have in terms of how to rank the results? That is a wonderful question. I haven't put much thought into that now. Monocular doesn't do much with that. And as far as the design of this, it's pre-alpha and figuring out how you rank things isn't something that I've put much thought into. The people who've been developing it may have put more thought into it. But there are things like official, you know, if somebody like the MySQL folks put out artifacts that are from them, it would be great if there was a way to note that and bubble those up. It could be usage if we're able to somehow determine that. But at this point, I really haven't put much thought into it. But that is definitely something that should be thought about. Yeah. Sorry, please go ahead. No, go ahead. You were just responding to a question on chat, but that we have two contractors based in Spain who've done the development and been so far been doing the partnering with us. But I do want to agree that I think it's a critical question. My most important focus on the results, I mean, if you just search for, I think MySQL is a perfect example where there's very likely to be multiple Helm charts for installing it. And you can imagine operator framework charts and other formats as well. The most critical one I'm focused on is how are we going to identify and remove any malicious ones that are trojan horses. But then the assumption is that we would be pulling in metadata such as GitHub stars or other kinds of indicators for it and then allow different forms of sorting and such. But I do think it's a really critical issue about how you percolate the quote best unquote option to the top. Thank you. Can I just ask a more general question? So I kind of get all of the all of the issues we had and some of the commentary that's been going on on the main list. Nevertheless, the concept of a service to find packages to cloud native software and to find cloud native software and deploy cloud native software is absolutely fantastic. And honestly, I think it's probably more key to the critical mass adoption of things like Kubernetes and the cloud native software ecosystem than probably many other things that the CNCF is doing. So from a support point of view, you have my full support and I think the support of a lot of people in the community to do something like this. That said, though, if the beneficiaries of this are the end users, shouldn't the end users want just a random list? Do they want a search engine that gives you access to repositories all over the place which aren't verified or curated in any way? And I kind of do really believe that there is an opportunity here to have the CNCF perhaps provide a curated list of different software packages because like I mentioned in one of the emails to the TOC the other week, things like the app repos and the RPM repos that the Linux distributions offer, for example, have been key to adopting Linux technologies. And if we look back at history, you kind of have these moments where mass technologies were adopted and almost all of them have coincided with a simple way to get a curated list of packages and software that ISVs and software vendors and the community in general can participate in that end users can consume. So while I'm completely in favor of something like this, I'm also strongly against just providing a random search engine list. It kind of does need to be curated and that could be the value added to the CNCF is providing. So may I make a couple of comments on this? Curation takes a significant amount of work and effort to do, especially when it is by hand. And if you look at things like the app stores that are out there that do a lot of the curation and put work into it, there's just a lot of work and people that get involved in that whole process. And so there's a lot of work. And if you look at things like the app repositories and the repositories for the different package managers across the different Linux family of Linux distributions, there's a lot of just time that goes into curating those lists. And we over at Helm discovered that it's very hard to keep up with that, especially with the pace of change that happens. For us on Helm, it has become un-maintainable for volunteers to do that work. And so I would expect we'll run into the same problem here if we rely on volunteers. So very quickly burn out and we'll be cycling through them because we've already found that at this scale. You run into that problem. To that point, Matt, I mean, this is exactly how Kubernetes is evolved. I mean, I can speak directly to, to storage. For instance, and having to test that and validate that and having confidence that what we're putting in customer's hands is something that is going to be useful and not potentially harmful to the customer. And I think it's still critical. I mean, essentially the community were all volunteers. And I think, you know, given the interest yesterday in the call, there are a lot of people that are interested in making this, you know, a lively accessible product. And I think if, if it's, especially if it's hosted by the CNCF that, that has a, that's kind of the rubber stamp of what people look to in the industry to have trust in it. So if we're not providing that level, I think that would be very detrimental to, to offering something like this. Yeah. Yeah. No. And I understand that with the whole curated thing, having gone through it, but I think there's, there's actually more to it than that. Because if you curate the list and there's many who are not on the list, then the CNCF starts to become the deciding factor in what's listed and how that's listed. And so of course it's got to be open and documented because we're very open. And then we're going to be debated on who's listed, why things aren't listed, and it's going to lead to a lot of complexities in, in that realm. And so it's going to lead to a lot of work. But then if you look at the ecosystems that have flourished many of them, and if you get outside of package managers, like apt and yum and things like that, and you look at things like homebrew, or you get into the programming language package managers, what they do is they normally provide. Well, everything and they give people the ability, the end users, the ability to decide for themselves and they try to make that easier. So if you look at something like packages, they provide you a ton of extra metadata about each package.  So you can decide for yourself, do I trust these people? Do I, you know, what information gives me here gives me trust in it. And so instead of the decision being the curators, the decision is put in the ends of the end users and they're provided a ton of information to help them make that decision. Because ultimately it's, if you curate, it's the organization making the decision and not the end users who get the choice or the end users can get the choice, but you need to give them a bunch of information and it's somehow towing that line. And do we, does the CNCF want to be in the position, the people who do the curation, getting enough bodies to decide, these are the things that people, the end users should have here. Or do we want to be in the position of saying, end users, here's what's available. And we're trying to give you enough information so you can make that decision yourself. And for me, I would actually like to hear from the end user community that we have as part of the CNCF, because I'm tentative on a group of people coming together to decide this is what we think you should use and we're going to curate out the others. And I personally fall on the edge of, let the end users make their own decisions. So that's perfectly fine, but I think there is a big distinction between say a software development package, like Humber or the software language type packages, because they are different packages. But what we're saying here is we're kind of doing this global search of metadata and now people can search for EtsyD or MySQL and get back 10 different results for the same package, except they're all different and some are supported and some aren't supported. And there's no way to know that unless you actually install the 10 different things. And again, coming back to the curation, there's no easy way to get that metadata over what's supported and what isn't supported and what's being maintained and what isn't being maintained unless it is curated. And just because it's hard doesn't mean it's the wrong thing. And I think the end users are a higher level than necessarily a developer, right? This isn't a developer looking at code. This is a DevOps guy or a team that need to install a database instance where they need to install some type of software from this repo. They're not actually looking to compare the 10 different ways of installing the one package. They're looking for the right way to install the one package. So I think that the difference here is that at CNCF isn't, I don't think CNCF should be signing up to be a distro maintainer because effectively what you're talking about is a distro maintainer, right? I can install the Ubuntu version of that CD or the Arch version of that CD or whatever. And I choose sort of based on the distribution who I trust. That's how I solve this problem. And I don't think CNCF wants to be in that business. So can we take one giant step backwards? I wasn't involved in these other CNCF projects that help enhance this. I mean, so would it usually start that the CNCF has a list of requirements of what they want to accomplish as an organization and they go out and have that developed? Because now I'm given conversations we had yesterday and on the list, then we were also talking about making this a sandbox project. So are we, which direction are we going? Because a sandbox project essentially can do whatever they want and bring it to whatever SIG is appropriate and go through the normal process. If we're talking about creating a CNCF-owned and managed project, I assume, I mean, is that going to follow the same thing or the two mentioned things that were before this? Were they sandbox projects? I feel like we're like getting way ahead of ourselves talking about what it shouldn't do and we're not even talking about how it should start. I think you could make the same point in reverse in the sense that there are some existing projects. Should we be adopting those as sandbox or should we first try to establish what kind of thing we want to get out of this kind of discovery distribution project? And I think that's why I felt it was appropriate to kind of start having that discussion. There's so many, I think, questions around whether the CNCF should do this and if so, to what extent. I think these points about curation, search ranking, they're extremely valuable. And what I was really concerned about is if we start getting some sandbox projects in, then we'd sort of, by default, be following a certain route or maybe a couple of alternative routes but that we wouldn't necessarily really have strategically thought about what is the best way for our end user community to be able to get hold of these different artifacts. But surely the sandbox is working well. It should be exploring those things with the end users as a discovery process rather than coming in with a predefined view of what it's doing. I mean, is the sandbox is very remitted to experiment and do things and not to have fixed ideas? Yeah, we could very well view it that way. I just felt it was worth trying to, you know, just step back and think about, is this even really in scope? And maybe it is, but we haven't discussed that before. Yeah, it feels kind of weird to me that I think there's two things here, whether there's the need for a more, they combine discovery for health charts, operators and other things. I think one discussion and what we want to have with it, the second one is for me still kind of like this, this process, how this went out. And no offense here, but it feels like some people had an idea. They hired people, they implemented it, and they represented it back, and now we should accept it into sandbox. I'm exaggerating a bit here. So I'm totally with this here. Should be first, but do we want this, that discussion should have started in the open? Should we really take an error and you brought out as well? Take like two steps back. What do we really want? Which value do we want to provide to the end user community? What is the best approach to go forward? And then they find how we want to do this, because even for packages, I can think of a ton of things that run into issues here. There's many distributions out there. How can I test this against my distribution? If there's 10 MySQL operators, some might work against my disk row, some might not work because they're not built properly. How can I even say, please don't install this against, and I'm just taking one here, Ranger or OpenShift. So there's a lot of discussions and taking two steps back and not discussing the project submission first, is the right way to go. If you really have to solve a problem for the end user community, I think a lot of the companies in here will step up and actually help. But so far they haven't been asked for help, really. And I think that's the route that we should be taking here, from my opinion. And we are now asking for help. So I would emphasize that this project is very interested in contributors, in having new contributors and maintainers get involved. So I put up some discussion points that, you know, pulled together from various different people's comments, and we don't have to take these in any particular order. And in fact, Diane just posted in the chat, does CNTF have either the mandate or engineering resources to host the infrastructure for, I guess, a marketplace hub? What's the funding model and resourcing model done? Do you want to speak a bit about funding for this kind of thing? Sure. I mean, the CNTF provides funding for things like Helmhub and the different parts of Kubernetes and such. So I think the key distinction I've seen so far is that if we're talking about a set of metadata that is automatically generated in some ways, for example, is this artifact valid or not, and that it's essentially generated in some sort of CI process, then that seems extremely tractable and very much in line with the kind of project CNTF has funded in the past. If we're talking about the App Store or Homebrew, and we're hiring, you know, dozens of thoughtful developers to pick the best artifact, then it seems completely untractable and not something, I mean, I would question whether even some large companies could afford that kind of thing. So I do think there's different ways of defining the project. I think the real question for me is where is the mandate for doing this coming from? And I know that we have started, there's a small project that you and Matt started here that we, I don't see where the end users are demanding this at this point, and it's good to be forward thinking. I'm not saying it shouldn't happen, but I have not seen anything of a request from the community for this effort. And I think if we could take another step back and really think about whether or not this is something that we ought to be working on and go out to the community and find out what they want rather than starting coding right away, sort of one of the tenants of review requirements first and get... I agree with that question, and that was one of our goals on coming to this meeting today to discuss. Yeah, because I think that the meeting that we had in San Diego that keeps getting referred to was really about having a very informal conversation about the unification of some of the stuff from Operator Framework and Helm, and it was about kicking off some cross-community collaboration. It wasn't really about kicking off any sort of CNCF marketplace, though that was mentioned at one point, but there has been no requirements gathering, no survey of the community, and no request from the community for this effort that I have seen in the public domain. So I'd like to see us take a big step back, do some research, stop coding, and make this into something that actually might be effective for the end-user communities. And I think related to that point is the question of... I mean, whether or not people should stop coding or not, I guess is a question for individual projects. Let's assume that the artifact hub, CNCF hub, starts to behave like a normal open source project. Do we want to... It feels premature to me that we would make an assumption that says there is going to be just one central source for this, but I think that does have consequences for the TOC assessment of projects. So, for example, do we want to... Operator hub at the moment is part of operator framework. Do we want to be acting under a working assumption that that continues as an independent thing, that there will be some kind of Darwinian action that decides which of these different sources should happen, should continue, should be the long-term place for people to discover these things? I think that is a real question for the community. Do we want to let lots of different things try to exist or do we want to set a more central direction? I don't know the right answer. Liz, the principles for the TOC are about letting multiple projects flourish, not making kingmakers, not being a kingmaker. So, I think in your principles, you've already addressed that. Yes, I think that the one reason to pause on that principle is, did we anticipate when we draw up those principles this idea of end-user convenience for finding these artifacts? I'm not saying we should or shouldn't have a central, you know, repository for this kind of thing. I'm saying this has very significant consequences for our end-user community. So, I think it was just a question that we needed to open up to discussion. So, I do have a quick thought on this, right? The foundation's mission is to make cloud-native computing ubiquitous, right? And there's also goals of fostering and caring for the projects. We want them to help grow. We want them to get out there to a wide audience. And this is all baked into the charter of how we can really grow this whole community. And if applications are much easier to install and find and discover, then that makes it easier to just share and spread everything, which helps the overall growth, because right now it can be fairly fractured. And we've seen large growth in the Helm Hub because it's made Helm things easier to find. But Helm isn't the only thing that needs to share. Some, there's projects coming up with ways they need to share their things. There's projects that already have them, like the cloud-native security hub, but that's still disjointed and disconnected and people don't even know where to look. And by making discovery easier, I do believe it's going to help grow the entire space because everything becomes more discoverable, easier to find, easier to use and install and get going with. And that will end up helping the end users get moving more quickly. I'd like to have a slightly differing view on that. I think there are already a number of curated lists of software, right? Helm Hub is one of them, but the operator hub has a certification process. The Rancher catalog has a certification process. Different cloud providers are setting up marketplaces.  We don't need to do a user survey to know that end users are finding it hard to navigate the landscape. There are too many options and giving them another 10 options to install one software package is not going to be a good thing. In fact, I'd actually argue that that might actually slow down adoption because it makes things harder to understand and it creates this perception of complexity and it actually slows down the sort of critical mass adoption where the technology gets adopted at a layer that doesn't require expertise at so many different levels of the stack. That's the point I'm trying to make here. If we are going to create a discovery service and this is a service, not a project, right? Whether or not we develop the software is another matter. But if we're developing a service that offers discovery, then it's beneficial to the end users. If it's curated and there's some level of clarity as to what the end users should pick. And it's not to say that we should pick just one thing. Maybe there are different packages for different distributions or whatever. That's fine too. But it shouldn't just be a random list of every operator or every helm artifact that's found in any GitHub random repository, right? There has to be some level of curation because at the end of the day, if we're going to do this, we're offering a service and this is not a project. It's a service that the end users are consuming and we know the end users are already confused by the state of the landscape. Nobody looks at the landscape picture that we put together because we allowed everybody to go into that and says, oh yeah, now I know exactly what to do. Nobody says that, right? So if we're going to offer a service, it needs a bit of curation. I just wanted to point out that an example would be NPM. NPM has no curation and it works quite well for people because of what Matt said about the metadata. So when you're going to load an NPM package, you look and you see when was it last updated, how many other people are using it, what's its license, and it's relatively easy to make a decision. So I don't think that curation is the great goal here. I mean, you could have a separate thing that does curation, but curation for an artifact repository is just not the right goal. So I don't think any artifact repositories actually do curation. Except for the marketplaces, I guess. But the marketplaces are a different kind of beast. I mean, I think that does.  Docker Hub doesn't have a curated part. Docker Hub has images. The official images are, the official images are curious. Yeah, it's a curated path. Well, that's more about provenance though, right?  That's a form of curation. I mean, it's a form of curation. It's not. I think it's more like making the maintainer up there. It's not really curation. So even if it's not curation, Brendan, would you agree though, if someone, so this is always from four years ago, this has been the issue is perception. And when people go out to the CNCF and they look at the landscape, and this is why we've had so many arguments over sandbox, people put their trust in this foundation that when they publish something that it is a good choice that it's been, you know, the due diligence has been done. There's some level of curation that, that they can trust that. So I think there's a matter of, if we provide this service, that people are putting their trust in us. And how much do we want to ensure that their experience and what they're using it for? At least from Alex and I's talk, we've done at various cube cons. So I think that's a good point. Every single talk, people come up and say, I don't know what I'm supposed to be using. How do I know when I'm supposed to using this storage technology versus that storage technology. And we actually have an effort in this thing to kind of create these patterns and use cases to help people navigate it. I have no disagreements with any of that, but that's not the job of an artifact repository. And you may be completely right. I'm just saying like, what is, that's fine. I mean, but I think that if you look at like Docker hub as an example, you're going to be confused about the fact that you shouldn't trust anything on Docker hub, or at least that you should make sure that you understand who the publisher is.  Right. And I think that if you build the right kind of index, sorry, I was great. If you don't want to index people know that it's just an index. Aaron, you were cutting out there. Yeah, I didn't mean to interrupt my internet connection is, I'm sorry, Brennan, I just, I would like to not have the same perception as Docker. I would hope that when people come to us, but no, but I mean, I think I'll go ahead. I was, I would hope that they would have a level of trust that when we. Put something out there, we're standing behind it. So whether that's curation or certification or whatever direction we want to go. I just want to make sure that's a fundamental idea that that is the perception. I guess, I would think, I think that it's, I think, I don't disagree at all. I think it's a good idea, but I think that there's a distinction between an index or a repository for discoverability, which is not something that I think really provides that versus a publisher, which, which is. So if CNCF decided to publish a helm chart, for example, or CNCF decided to publish an operator, then I think you're absolutely right. People will expect that it's supported and all sort of thing, and it should be. And so if SIG storage or whoever decides to say, hey, this is the, you know, this is our operator for this database, then absolutely people will trust that and they should. But if we're talking about discoverability search, then I think the job of search is to, you know, is to provide you with the results, all of the results and let you decide. And obviously, you know, when you get into questions of ranking, then we actually have to take a certain amount of, you know, authority into account. But we're not talking about ranking yet. And so I think I just, I want to make sure that we don't conflate, you know, the discovery and search parts of the problem with the publishing and therefore the reliability and authority parts of the problem because they're distinct. I think kind of related to that reliability part of the problem. Ken was making some interesting comments as an end user in the chat and saying, you will never meet my security requirements. Ken, do you want to just elaborate on that a little bit? Ken, star six to unmute. Hi Ken, if you are. Sorry about that. My company is shut down on non-essential communication. I have to use my like my personal phone for these calls now. They don't consider CNCF and essential use of my job. So sorry. Trying to navigate things on the cell phone is not easy as on a computer. Yeah.  And we have a business that we're trying to support and, and, you know, things like fraud and analytics. Um, aren't hard to figure out what we need to do. And so for the most case, um, our requirements, we do not, whatever you think you're going to curate for us, isn't going to be curated enough. So we're going to curate it ourselves. No matter what you guys try to provide.  We have about 17 different pipelines that go out and curate for 17 different artifact repositories. And then itself is not hard to solve for and something we solve for it, but, you know, having a single place for this type of use case, I think it makes a lot of sense. That's great feedback. Uh, I think like it'd be nice to just, it doesn't seem like people object to this initiative. So I'd really love for us to talk about how to kind of move forward, but then also leave room later to kind of build on these requirements, uh, with specific end user surveys, like can just provide it really good feedback. Um, so maybe if we could find a nice MVP to, to agree on, we can just move forward from there with hard data from end users on, on what features we really want to support. And I was about to, um, to chat on the chat message that Cheryl is on the call and she hosts a, um, end user, um, meeting every week. And so we could, um, you know, bring this up as a discussion point, um, in one of our future meetings and provide, you know, some real time feedback to you guys. That'd be great. Absolutely. That would be great. Yeah. Yeah. I think you know how to get in touch with me already. I'm really happy to connect to you with a bunch of end users or invite them to join a future TOC call. If that's easier and give feedback in this form. Yeah. Well, very, well, very, very adamant on the no key makers type of, um, you know, um, Charter that we developed in the CNCF. And so I don't, I don't believe any of the end users are wanting to make or trying to provide any sort of feedback that would allow any sort of key making to happen. And so I think in general you'd be very, you know, pleased with the hype of, of interaction and, um, feedback that the end user community can provide in this area. Uh, this is Matt Farina. I'll take the action to reach out to Cheryl to set something up with the end user community. That sounds good. Yeah. There is one other sort of group of constituents that I think we should just be aware of, um, you know, that our vendor community are part of this. Um, I guess I just want to flag up the concern that, you know, everybody is going to want to own a bit of this. And I am very concerned that we make sure it, it maintains its neutrality. And if we're going to have a single point of, uh, discovery that it's, you know, I think we're all on the same page about trying to find a neutral way to, to present these different artifacts. Um, but I did just think it was interesting that, you know, the fact that Docker owned the, the Docker hub and were able to, you know, maintain that site and continue to maintain that site was probably an instrumental part of the success of container images, Docker images. So I just, I, I wonder whether anyone has any thoughts around the impact of this on vendors and whether it's a good thing. And it may well be a very good thing. I just wanted to raise it as a discussion point. I think actually though that the presence of the Docker hub kind of put a chill in the ecosystem to a degree. Because it may have been good for Docker adoption. Maybe, maybe, but I think a lot of ecosystem people saw it as Docker putting their, their sort of thumb on the scales to try and lead people towards their product. Which was not good for it, which is not good for the ecosystem. And so with us, I think having it in CNCF is better because it means there's a hope of neutrality. Yeah, I guess we've ended up in a situation where it's now being maintained by, you know, a company. But it did turn into a free way for lots of people to, you know, I think we should distinguish between two parts of the hub. I think one is the free image repository, which I think was very great. I think the other piece was Docker's decision to make their own images sort of privileged within the hub. Which is, I think probably not good. Right.  It would be great to capture those concerns Brennan so we can avoid slipping. Sure. Yeah. I mean, and I know Joe, Joe beta and others are some of the people who really brought up this concern a long time ago with Docker about how like, I mean, and I think Helm would have the same problem, right? Like one of the good things in Helm three is that you have to install every Helm repository via URL. There is no, you know, Helm stable, whatever isn't just sort of built into Helm. And that's so that again, you don't put your thumb on the scales. And I think if you look at any of the good package managers that are truly open, this is true. Like apt, like apt, you have to have a file that lists all your repositories. It's not like it goes to Ubuntu or Debian by default. And, and I think one of the challenges with NPM historically has been that that wasn't true. And I'm sort of optimistic that now that it's part of GitHub that's going to potentially change. But I think those are some principles that are really important about, about sort of not having the tool be too tightly bound to any particular repository. Yeah, I think that's a really great point. I agree. So what are we doing next? Liz. So I, I think this has been hugely helpful and productive discussion. Was there anything else? I guess there was a kind of community call from yesterday. Was there anything else that came up yesterday that maybe the TOC should be aware of? Well, there is one thing, right? So there's been the discussion early on of, should it be a service or should it try to come in and structure as a sandbox project? And the call yesterday we were leaning in the direction of a sandbox project and run it like a CNCF project. But it is also similar to the services like dev stats and things like that. And there's just so many services the CNCF offers. And so I figured it was probably worth hearing the TOC's thoughts and getting some direction on that since you all are the ones who make decisions about sandbox projects. That point. I guess my initial sort of feeling on that is that it's probably easier to go from a sandbox project to a service than the other way around. So perhaps while we're still in this early phase and you probably don't want to be signaling too strongly to users that this is in some ways sort of blessed yet. Maybe sandbox is the better experimentation approach. Yeah, I would think so. I mean, Dan specifically said it's pre-alpha and no one should use it at this point. So I don't see how we could possibly agree to run it as a service at this point. And given that there's so many outstanding questions about what kind of things it should and shouldn't do that are quite fundamental, I think it makes much more sense for it to apply as a sandbox project. The other part of yesterday's conversation was also that if we ran it, if it stood itself up as an open source project that it could be something that CNCF ran as a service or someone might run and stand up internally as a service behind their own firewall. So if we created this project in a way that it could be deployed anywhere and CNCF just created a service out of it that might be a way forward here too to help folks like Ken and others who aren't allowed to trust a service provider like CNCF or Docker Hub for their compliance. And just to reiterate Diane's point that's how it already is set up that the software is all Apache 2.0 and can be running independently. And then CNCF would be running a privileged version of it or a well-known version of it but not the software wouldn't be any different. I think that's a great point and sort of learning again from history, Docker registries and so on people being able to run their own instances would be really valuable. Yeah, I think that for me part of the I think the curation conversation here is a really good one. Also the testing and the CI CD pipeline behind it. We've had lots of conversations with people around the operating framework and testing and certification and how important that is. So getting that right in the infrastructure is going to be key. And I think that might take some reframing and rearchitecting of the existing code base. I just wanted to say that running a service is actually very time consuming and it takes a lot of resources so yeah, so having that choice for people to run For people to run the service internally in their own, in their own organizations, I mean, it would be great. But, you know, thinking about like hosting repository repository for everyone around the world, you know, you something like that, you know, CNCF would do what required a lot of resources and, you know, something that will be able to handle like large scale deployments right so So maybe that will be something that could be used for certain types of users that wouldn't require large scale, but if you want something to have reliability and, you know, redundancy and all those different type of production type of things, you know, having that choice to run it in their own private networks or their own cloud will be great. I guess it's also possible that people could take instances of the project and, you know, host their own public versions for particular types of part of that if they say chose Right.  Yeah, and I think the one difference here is Docker was actually hosting all of those images and those large files and so they had to do so many things because they're doing the hosting that and this is a lots of artifacts are distributed all over and this is a centralized metadata search, and it doesn't do the actual hosting so it isn't holding all of the helm charts for example, or other bits that are going to come in after the helm charts. Those are hosted by others. Many of them are vendors, and that really lightens the burden, because it's essentially a metadata search which takes a lot less resources. It doesn't one caveat of that is the possible introduction of any number of broken links. And how quickly that metadata is refreshed and the hub updated, given that that won't be a well it'll be a curated but uncontrolled experience in some respects. Just just something to watch out for it'll be eventually consistent dependent on update cycles and catching and notifying. If somebody for example has they've said here's a group of assets that need to be listed, and we've detected problems. How do we unlist those how do we notify people that there's problems because many times they're accidental. That's all just in building that out and building out the user experience not just for the end users, but for the people who list their things to be curated as well. With three minutes left in the hour I just wanted to briefly touch on operator framework because we put that assessment somewhat on hold, so that we could have this conversation more broadly. In the remaining three minutes does anyone have anything they want to say about it. Operator framework and what we should be thinking about in terms of that project. I mean I think we're hearing it's no king making. I'm not here. I'm here from a seed. We are a security company and I mean operator hub is considered as the North Star or very cool concept of operators but I'm wondering like from a security perspective like what kind of the diligence was made around you know introducing components into that in some cases. It's a kind of sense but in some cases it's a nonsense. And, you know, speaking here on CNCF hub and the resemblance into operator hub would be interesting to hear like what's the to see perspective on that. Along the lines. I was going to say that. Having had all this discussion the TSE sort of owes the community a description of what our goals are for this kind of stuff. I mean I have no problem with just putting all, you know, put all the hubs into sandbox just like we've put lots of other competing projects into sandbox, although, you know, so it's a TSE decision, not one person decision, but I do think also given all the sort of discussion we owe the community a description of like, this is what we're thinking about. I think it was going in as incubation. And I think it was going in as incubation. Yeah, and that's a higher bar then and so yeah. Absolutely. And, and we should definitely Would one one consideration maybe I mean, you know, just an idea maybe splitting the operator hub out from the other parts of operator framework and then because I think it would send. I think that's I think that's a great idea to Yeah, and I think we talked about that at length as part of the zig zig apps discussion and I don't think that was contentious say but but would it be worthwhile since we've had this very long thread going on in the PR to maybe be back with the project and clarify any misconceptions I just think a lot of things have been lost maybe in that I think maybe the TSE needs to have a discussion. I think, you know, I think at this point TSE needs to have a discussion and owes a response back. Yeah, completely. And so why don't we set a goal. Liz, how do we set a goal of getting that. Oh, sorry, someone else is talking. Yeah, so this is others from the secret deliveries. I think the operator people have been waiting for quite a while so I think, giving us some attention right now it's definitely the right time just what I wanted to point out and if we can get this. And one of the next to see me that would be beneficial I think it has been almost for me to four months that they have been waiting. Yeah, I think we've I mean, I think we should probably just commit to doing any private TSE email thread and get it sorted and, you know, by say the end of the day tomorrow, something like that. I don't know. Liz, what do you think. Should we say this week and then this. Yeah, I feel like that puts like not quite enough pressure on everybody and we'll let it. I'll take quite on it. Great. Great. Wonderful. Thank you. All right, I think this was really productive and helpful. I hope everybody feels good about this kind of getting some of this out in the open. I'm sure we'll be talking more. But thank you very much everyone. All right. Thanks everyone. Bye.