SG13 Minutes 2018-11-08
Roger Orr
Poll 1. P0267 - worth spending time working on issues brought up.
- For: 8
- Neutral: 4
- Against: 1
Poll 2. Web View: worth spending time working on.
- For: 7
- Neutral: 4
- Against: 2
MM: Michael McLaughlin
TH: Tom Honermann
AP: Antony Polukhin
RR: Rene Rivera
JB: JF Bastien
RO: Roger Orr
TD: Timur Doumler
BB: Botand Ballo
MS: Mike Spertus
RS; Robert Simpson
HF: Hal Finkel
DL: David Ludwig
GD: Guy Davidson
MW: Michael Wong
8:37AM Start.
RO: What fits in SG13 is a question. Vexing question of text and unicode. Also discussion of Audio and other things as well. Who is in first SG13 group? (MM)
Started 5 years ago ?
MM: Yes I was in first one.
RO: Stopped 2-3 years ago.
MM: Yes, 3 years.
RO: Paper is now R8. Didn’t want to proceed further, caused concern with NBs. There was an evening session in RPSWL and the end result was a lack of interest in lack of proceeding. Concerned express about the process and a binding decision in an evening session. BSI was exploring the idea of having a TS under the BSI. BSI doesn’t publish its on TS just those under ISO. They do their own but requires own funding. Discussion with other NBs, and the idea was to go some where. P1200 - request plenary to send back to LEWG, then an alternative approach put forth by Herb. To start back SG13 to approve consensus. One approach are there parts that can be split out and are they useful on their own. Mike and Guy have given some thought on what is possible. Something to think about.
RO: I am new to chair, I am keen on the proposal making progress. But want to get an idea of those are here and what the interest is if any. What directions are we keen with.
MS: In the evening session - there was a radical different approach from Hal. In order to approve consensus.
MM: Hal is here.
JF: He is here.
TD: Shall we try to get him here ?
RO: One outcome is to publish two different papers.
BB: Web view proposal.
WM: My background etc.
MM: Working on this paper. Invited to Urbana Champ to discuss paper. Now working on R8 of p0267
RS: Graphics for 15 years and working with 2D API, moved to compilers and other areas, and I am interested to see why c++ is involved in graphics.
MS: I have two interests - adjuct to education - there are some includes in BS’s book, and I teach c++ at U of Chicago - and have a perspective on the language. I also work at Symantec. C++ is worthless in some aspects without graphics.
TH: Not an expert in graphics. My interests, we have a system language, and we are not getting to a place where the language can be. From the text perspective, how those mesh together.
AP: Russian NB. I have no experience. I am generally interested to making language popular, and we need tools in a uniform manner. This is just not my opinion, but others. They want portability.
RR: I started in graphics programming. Which I never left. I do games, for 20+ years. Intermixed with AI and teaching and interactive stuff, related. I am interested in graphics in a ll types of platforms. I am not happy that it has volatility in the standard.
JF: I represent Apple. I authored one of the papers we discussed this week. I work with Clang. My team would be interested in graphics. I collected feedback from some of our experts at Apple. If we do put graphics in c++, we want to deliver a good solution, does it drain battery life, etc.
RO: I already said why I am here.
TD: I am not an expert in graphics. I am expect in Audio sound. Two reasons I am here. First reason is what AP said, we need what c++ provides, and you end up using APIs from different sources, some of which I have worked on. That is not the optimal solution. That isn’t fundamental. Many reasons why c++ should provide a standard solution. If you want to write a pac man game, think about the areas in which you must use and we must standardize. Second, is a standardization on how you work on your sound card. Third reason is to find out if my paper on audio is in scope.
HF: Area of general interest. Background in in HPC, many years ago at an ISP I worked on a interface that was distributed with a user base. My experience comes from that. My overall feeling is one we should aim to do something that is sufficient scoped to be useful. I wrote the web view paper. I think it is a potentially way forward, it may not a viable way forward, but potentially. If you are going to provide a useful way to do HCM interaction, must provide a wide array of options, its a lot of complicated things. You have to be able to communicate with them, audio, input, touch screens, etc.
Many environments. I am skeptical about creating a sufficiently board solution, which motivated me to look at if we can leverage other web standards, I thought that was to restrictive. My experience comes from - collecting input from users, managing configuration, etc. I need to create text boxes, display progress, and such. All these things are not technically out of reach, its just not clear to me can we create de novo all the things we need and process out of this committee. I want to leverage outside standards and work, I think its the only way that is sufficiently for the committee.
DL: Been working in games for about 15 years. I am on a sabbatical. Game tools, game design, game programming. Mostly in 2D games. Proprietary engine. Some libstl work. Nothing elite level contributed, but some. Some work on reference implementation but nothing near the work that MM or GD has done. Just some reference implementation.
MM: Can you hear all of us ok ?
RO: First things is proceeds is to have meetings like this one at other meetings. But what should we do in-between meetings. Telecoms, mailing list. Thoughts do people have ?
MM: Telecon. Most practical. Given our locations, etc.
TD: +1. Works. Mailing list.
TH: SG16 Works well the telecom.
RR: SG14 works well. Well organized, structured. Good flow.
RO: Only SG14 I attended was in Oxford.
RR: Michael Wong does a very good job.
WM: SG14 works well.
RO: Good to get input from other expertise areas.
TH: Not a lot of papers to discuss. Moving onto to bigger things and incubation. I would also add having a slack channel. And a publicly available mailing list. Ad hoc interaction, and more in touch with people. Permanence of information is not as easily searchable as email.
MM: Slack could be useful - has out some details. Mailing list would be a better way to go.
TH: Slack is nice, but mailing list is important. Informal chats don’t clog up the mailing list.
RR: One idea was to use slack on what to write, bounce ideas on other groups. Finding people in the moment. And mailing list for longer term discussions.
RO: I have not thought of a slack channel. Depends on how much discussion that is free form.
TH: Some younger people respond better to slack.
RO: Easier to access with a app on your phone.
JF: Easier to bring in other experts on - if you want feedback from those areas, you need a meeting where the experts are. You will need to come to graphics experts area. It is highly unlikely you get focused feedback unless in the area.
TD: Why is that a reality ?
JF: Other companies in bay area don’t care about the day-to-day standardeze of C++. Make it convenient for them, they’ll come. They have ignored this group, it isn’t a priority. If you want to talk to them, and get feedback, has to be in the area. SG14 is the C++ road show for gaming/embedded/finance, we should do a little road show for graphics. The goal is to bring C++ committee to them. Look at SG14 for inspiration of good collaboration.
TD: The audio proposal is a similar paper, we have a draft. We will present to the audio developer conference. From then on, was to have the slack, telecom, etc.
JF: This is a great approach, take it to the conference. A lot of the graphics experts live in the bay area.
TD: You are not worried you will exclude experts from other side ? Not a bias towards that area ?
JF: You can ignore them if you like. It missing some key items. The current state of 2D graphics tells me it’s a bad idea to ignore those experts again.
RS: Lot of trends moving to slack, some slack tools might be of concern, due to rights, etc. Be careful and make sure you use a proper tool. We need to get the word out. And people will follow. We have looked the various APIs. In the UK we have many experts all over and in Norway. Have a face to face in Bay area, but it isn’t the only solution.
DL: Can someone explain the road show referenced the road show concept.
JF: Sg14’s audience had been ignored by committee before C++11. You need to go to where those people are. Bring that input back to the committee. So those people don’t have to go to the committee. One example was the EASTL. What I mean is you need to bring the committee to the experts.
RR: Its rare to cover papers on the show, its more feedback from the people. What are your concerns. Not be shy, try to get feedback.
RO: How does he manage to get to all the places he goes. He is very active. Perhaps I need to talk with Herb about getting a co-chair.
MM: If the chair can’t make the meeting to make an active chair. If you pick a permeant chair, and they can’t be there, you run into the same problem.
RO: Can people make a meeting in bay area ?
MS: I am concerned the number of people in this room.
JF: The one person in here that has experience in graphics is chairing SG1 all week. Bryce, who coauthored the graphics lite paper, is chairing LEWGI.
MS: Is this epsilon or epsilon squared.
RO : who can ?
MM: 2D graphics from onset has been focused on hardware. We standardize interface, not implementation. If you look back 10 years in graphics, the early years of shaders, 15 years then you get into fix launching pipelines. It will continue to evolve.
JF: Hardware vendors, some make not make hardware, just ship it. What they want is their product should be really good at c++. My point is not is that it has to work 100 percent to maximum of hardware. If you want it to work well, you need to talk to them.
RO: These are the primitives we could offer the hardware guys.
JF: The discussion has been very specific about topics. Like dotted lines. This is something hardware can accelerate, and it’s not clear the current proposal makes it possible. My graphics experts say “can I draw the lines faster?”. IF you design is better, these can be done faster.
MM: I would like to respond to that. Which is, post Toronto, separate backend from front end. Programmer interface. There is a defined API. Then the backend can be written to take full advance of any hardware. Can be made efficient from power consumption. I can’t start sending emails to random people.
RO: If we had a bay area meeting. Could be a useful conversation and have some buy-in, input, etc.
JF: There is a data point which shows we can’t get groups to talk to each other. We need to talk to them. We are not doing a good job in the committee.
RO: We have some practical constrains. SG5 had a meeting on one day. They were present for that one day, one event.
JF: They won’t come unless its in bay area. Even here in San Diego, there’s no new experts in this room.
AP: Send me an email with what experts you need I will find them.
TH: You need to be as open as you can. Be open, accepting, publication, outreach, etc. There is no one right solution, just get out there. Many different communication medium.
RS: There may be more than one way to do this, some expertness that attend these meetings. We need to understand how people what to use these APIs. There is increasing trend there are liaisons between companies and committees. A lot of these APIs lead .. and they are not graphics APIs, they are more hardware abstraction layer.
RO: Do these people go to kronos meetings?
JF: Not really, though the head of kronos graphics is at google.
DL: Any online communication would help. It can be hard to get the conversation started. Here is what we have, lets test in person. Having any form of communication online or not is a good thing. Conversation sounds cliquish. Some benefits. Go out to people and talk to them. No matter the terms.
HF: Michael Wong Talk to him. He is heavily involved in standardization of kronos. Don’t confuse abstraction with efficiency. Those backbends can target specific hardware. This is an independent set of design points. I assume you know this (directed to MM). its not they are abstracted, just putting them together. Another thing I wanted to say, basic operations have not changed since post script. That is somewhat true and post script good idea to abstract. We need to think about what people are building. For example accessibility is a big feature. We may need appropriate screen reader meta data. Other things that are applicable to post script. They are not general features of historical graphics API.
RO: Guy is now on the call. 937AM.
MM: The suggestion from the TS, there wasn’t a chance to integrate into the paper. Are there issues that can be modified, changed, etc. Are there design aspects prevent certain optimizations, that can be changed to achieve the goals better. We can try to mentally model them. Unless we implement we won’t catch everything, all the pain points. We can keep going and going, but we have reached a point where we need to see some people write and get feedback. One other things. We inventorially decided this will not be at a user interface level. The highest level a service we are leaving vague , in the same way c and c++ was the input and output was a console. If you look at the standard, you don’t see the console mentioned anywhere. The reason is to avoid constraining people. If we did, it would put limitations on various vendors.
HF: I understand, but I disagree.
RO: Adding was one of the criteria for the TS. There are other implementations strategies. And we can encourage them. Some of that you can ascertain on certain platforms. There is an important feature we can get access to.
RR: Speaking from implementation, the meta-benefit of boost gives you a large audience for testing your feature. It would be nice to have any form of graphics go thru something like that, the reviews, the challenges make you really hard looks at what you are doing.
MM: Back in SG13 when this began, this boost discussion came up. Beaman suggested not to go that route. 5 years later we can bring this discussion again. A TS would be better at this point.
RR: That is probably true at this point.
RO: Making we make existing implementation more readily available. I am not sure if others are aware that there implementations available. My view, there was a tie into Cairo. Some people seem to think there is a tie in. Into a range of platforms.
AP: Why do you don’t understand why you don’t want to go to Boost ? You need experts and more users. Go into Boost, you get feedback from other libraries. Those experts will you give you feedback on other libraries. These are not just graphics experts, but other topics. And other integration experts.
MM: I can’t speak for Beeman. It would possible to take P267 API and I would dilemma to see it go out as TS, but separate from that, get it together, and try to place into Boost. Go through both processes.
MS: I will agree. Putting it into Boost would be fantastic independently. Speaking from my concern. It is very much the norm. If you want production experience, Boost is much better way.
AP: You can follow the ASIO approach. With a fork that is different from Boost. Some people like Boost, some don’t.
MM: Lets talk later about this.
RO: Which implantation to you place in Boost. Getting build system tow work with Boost has some overhead.
BB: I have a clarification from the multiple implementations. Is there a single platform with multiple implementations.
MM: Yes-ish. Mac OS X - native Coco and X11 and XWindows which will run. Its decoupled from OS, you could consider it two implementations.
JF: Its in same repo. Is that what you were asking BB ?
BB: Which can you place in Boost ? That is my question.
MM: Coco implementation was wrote on their own and reached out to Guy. This was separate and based on the proposal.
RR: I was curious was that what you meant, there were multiple APIs addressing same space or same API ?
RO: The individual authors had different views on the implementation. When you download from Boost, which do you select ?
RR: This has come up before.
RO: I think we spent a while how best we can get involved on going forward. Who can make it to bay area if we help a meeting.
RS: The issue is why are we doing this ? What are we going to get out of this ? If I can show them something with reason and get an answer. I am not going to go there to try to work out the problem to the solution.
RO: Perhaps a more specific proposed agenda. Can you do it AP?
AP: Shaking his head negative.
RR: Can’t for work.
MM: I represent myself and can come. If there is a specific agenda I can consider it, if its the right way to go. I can’t make any guarantees as of now. Without seeing concrete agenda.
RO: Many of us are going to be in Kona. Maybe a day after Kona ?
JF: I think now its too late. Some people book vacation before / after Kona.
RO: Given people in bay area. Perhaps putting something out around WG21, mailing list.
RR: Do what Michael Wong did. Day after, etc on some of the expert related conferences. Putting something around those conferences. That are graphics related.
JF: Reach out in advance.
RS: I suggest GDC in Feb/March.
MS: It makes sense. Are we doing low latency at cpp con. Maybe there, lots of intersection between the groups. Gaming people are not in both.
RO: Slightly wider question. Which criteria should be decided on what should be covered in this group going forward. We have web view, audio, human machine interaction, and IO. It would seem to me we are looking at graphics, anything involved the screen would be scope. Touch audio in scope for this group.
RR: AR/VR/MR - screen tracing. Haptic feedback, motion capture, etc.
AP: Are we going to deal with file system. Pipes, memory mapped files.
RO: File system SG1 is closed.
AP: No one is doing pipes, memory mapped IO.
RO: If we go this proposal in form of a paper, there would be discussion between myself and LEWGI. The other group and who would take the paper. The other question is what proposals belong here. And also something we want to standardize in this context in c++.
AP: I am interested in 1031 input output low level API library. Probably one of the papers we should discuss.
RO: That is SG14. It was raised in SG14.
RR: Still in SG14.
RO: They are more useful that human machine interaction. Which is the poster child for this group. Perhaps LEWGI is more appropriate.
TH: Did you want to broaden the scope to pickup more ?
RO: We could try that ?
MM: My concern is when papers come in, trying to decide what is in the scope, its hard to do.
TH: I am in same boat SG14. Talking about features that people might want. Put together.
RR: Putting out a broad calls, with more subjects will get more responses.
TD: Try to avoid - years working on graphics proposal - then subset of committee to say they don’t want this at all. I would like before i start pouring work up from the direction a paper may take before i spend the work.
RO: Its a general concern. For subgroups. Before it makes it way o evolution. It is question to raise with Herb. How do we make sure the study groups get opportunity from feedback from the community. Given that would be useful to come up with some areas. David you had a few fields SG13.
DL: Windowing, event loops, messaging. SG13. Event handling. Some of same problems of audio.
TD: Audio is much easier. Mac, Windows, IOS, one way to do this, APIs are different. Fundamental audio channel description is done. Makes standardization much easier.
RO: What else do we have on a potential short list?
MM: Other input devices. In graphics we wanted to do output first, we would then take all the knowledge and use to build the input on top of output.
TH: Feasibility on sync between input and output. Is it reasonable to design separately ?
RR: Currently working on code dealing with this. There is a gigantic area of research in this area. We need to keep in mind how much we are getting in and sending out.
RO: Suppose someone came in to do a GPS API ? Feedback or beyond our scope ?
TD: I have an idea on how to prioritize. Might be in scope. One way to look at this. Assume we have graphics. What you need else ? You need a window, mouse, sound. You can’t a complete app without a complete graphics. Second level, this is extra stuff that modern devices have. Phone has accelerometer, all these other IO channels. Is that helpful to think in that way ?
RO: Helps yes. On which ways to focus on.
TH: Window management. Interacting with desktop. Then the top, rendering.
TD: If you don’t have a window. You can’t do anything. You still need a handle. Which graphics doesn’t provide. Right ?
MM: Yes, it doesn’t provide.
RO: Look at cin and cout. We didn’t specify the output.
MM: There is a user output design, we don’t constrain depending on the window. Its abstract from output sense.
TD: Windoing is a thing that is important.
TH: With that you have a windowing system, menus, etc.
RO: Line, text, etc. WE have that down. Any other thoughts, on future proposals.
MM: I think TD raised a good point. Phone. Not sure committee has any role here, but I would add HMI areas.
RO: Do these benefit from a standardization ? Such as TS memory, which gave direction to hard ware manufactures.
RO: Break is now. 20 minutes, we will resume after. Brainstorm after the break. What problems are we trying to solve. What are the daily problems, use cases. We have multiple proposals in the space. Which covers what, details on the papers agenda.
TD: Audio proposal feedback would be nice.
RO: WE can discuss.
AP: Please proceed.
Break 1020-1045AM
RO: We left of before break about Audio and support. And a possible feature for Timur.
TD: I can give a brief introduction. Frustrating is every device has audio. All day same thing at low level. Some platforms abstract that way. But they tie that into their build system, they are not c++ or c. If you write an embedded system, there is not just value to probvide, but also a standard interfact. Solves many problems. Idea is to provide a memory level to access the sound card. Everything can be done outside of that. Memory would be standardizing existing practice. Very quick way to enumerate devices, handles to devices, calls for event registry, buffers, write and reading to buffer.
RO: Idea is to write standard and a reference implementation.
TD: I am currently working on standard. Compared to graphics, much less code. Decent chance to have several implementation working before Kona.
RO: You can find out what is missing.
TD: Exactly. We want feedback, find missing bits. Some bits are not essential, some are. We just want feedback.
HF: Would this support playing audio in certain formats ?
TD: There are two levels. We are confident to have the IO level done. Reading and writing. Then there is the File IO dealing with compressed formats, this is level two, we have not gotten there yet. Ideally you have a file writer and file reader. Decoder or encoder.
RR: Speaking of coder and decoder. Much of HW has support for encoding and decoding on the hardware. How do you handle that the HW has already encoded or decoded ?
TD: Interface would specify whereto you encode or decode and allow platform to accelerate ? We have not designed that interface yet.
MM: If you have expressed the intent you plan on making the second level, if you make it clear. Might sell better.
TD: I think the level is needed (second one). As of now its a time component. Level two will happen later, just don’t have the time. I am more on music production side, and other developers are game developers. We are split on work.
MW: One more thought, a question. Are you considering committee interfaces ? They would not use MIDI, might not be relevant now. There is a MIDI standard, would be easy to standardize, for c++. Not very challenging. No time now at the moment.
RO: Your paper would include in your paper a roadmap.
TH: Low level portable hardware audio, is not very portable.
TD: Its easy to separate audio and make it portable. Linear sampling audio. The numeric format can be different or interleave them, or channel them, easier to do.
TH: Different microphones produce different audio streams. Is that the case ?
TD: That is at the hardware level, We would be above the low level OS APIs, that is all abstracted.
RR: The audio that you feed the cards is usually something like RDMA, but its all the same, objects passing around.
TH: There are somethings you can do with this.
TD: The work will be done by audio experts. How would you like to approach this to the group ? What should I bring here next time ?
RO: Two questions. Do we support the idea of bringing a paper for Audio.
Poll: Do we approach having a paper be present a paper to Kona on Audio:
11 For
1 Abstain
0 Against
TD: This is draft 0 of proposal. Or what is Audio, what does it do, etc.
MM: One paper, covering audio basics, and one covering the roadmap.
TD: It isn’t that hard really.
MW: Roadmap of what you would like to do. Current thinking now.
TD: Not present the first version of the API.
MW: I would rather want to see high level proposal.
HF: I would suggest splitting this out. Evening session would help for overview of audio. Details of modern audio. Then you could present the proposal. When you talk about audio, what is the space of application use spaces. What part of that roadmap addresses certain use cases of audio. What are the interaction requirements. For this subset of applications, I need audio interfaces with high accuracy timers. This space needs audio, but needs to synchronize with graphics. So that we understand what the universe is, what pieces cover what parts. What are the required interactions, what covers what.
TD: Educating the committee is good I just struggling taking time away from committee.
AP: A API example would help selling the paper. Short example and people will love it.
RO: Sounds like a general evening session on audio,
TD: Is it realistic to have an evening session?
RO: I can ask.
MS: Yes it can be concurrent.
RO: Ask as early as possible. (For Kona)
MM: If you want any help ask me. Happy to help.
TD: Guy had told me some items.
RO: Back to 2D graphics. Principle reason this group was formed. Meta question, what problems are we trying to solve ? What are the use cases for existing proposal for web view and what is the universe of stuff. One of the problems that have been obvious is a big area, and covers a lot of target audiences. No one proposal covers them all. Seems to me if Michael could give a summary. Tied to the current proposals. There was a paper, tied to this, N paper.
MM: The last time was that information was included N4073. Guy has written much more up to date papers. Those are in the Rapperswil notes. I can incorporate them. But we aim to do is provide a lowered that UI level of 2D graphics. Output source , a window, a screen, a file. A memory mapped file. And have the basics operations. Output, text. Text is the next step and that will be added in. Then input is final step. Simple reason without having output nothing to send input to. Graphics being a large area, splitting it up, rather than one huge proposal is what we aimed at. We avoided windows, UI, widgets. What we are doing is for people to build something on top of. That quality implementation is a key thing. You can have a horrible implementation that eats your battery. With a good implementation you can have fast performant. Are there things that prevent higher quality implementations. And can we avoid them.
MS: What I would like to see regarding an explanation of how this is proceeded. Most of what you just said and discussed in reflector in the evening session. Where this was voted down. I would like something … what wasn’t raised before. I can’t really translate an overall summary. Full P0267 was voted against by me. I didn’t think it was appropriate for some use cases. I did value some. So, just saying the same thing again will not change my mind. I have an open mind, here is something that wasn’t raised. How its used, or more suitable for these cases. I am not going to sift through. Find out I need to read a largely similar thing and come to a different position than before.
DL: For those who rejected P0210 - was it the implantation as source of concern ?
HF: I didn’t hear that concern expressed.
MS: I can say why that at least for me it wasn’t about that stuff.
RO: Intersection of P0267.
MS: For simple users of c++ and first few weeks its hardest thing to do. Hello world is hard and this is more complicated than that. Java is a 2D library, their swing stuff, if you would be doing Java today, they would not have done swing. Why are we not making those concerns. My concerns are higher level. If you reject some low level things would not have an effect on me.
RO: You want a higher level library, or something easier to use ?
MS: Web’s approach, language lacks a framework for these types of things.
MM: Before we took text out, you could write a graphical world in 10 lines. When we took text out.
TH: Education or presentation problem then.
MS: if its an presentation problem. Swan books does 2D graphics. Useful even when people who don’t use c++. If it isn’t suitable in these use cases. That would be useful for me. I am not saying my vote can’t change or not, but that would be helpful to see.
RO: Want to talk about web view and some use cases.
HF: Overall philosophy is a way to standardize user interaction. Does that by calling to HTML standards. In that set of things. The idea there not to target high performance graphics, target graphical or multi modal user interaction. Provided on majority of devices users interact. Or smart watches that users use everyday. Import thing here, my experience here, when your doing graphical development, event if you are doing a game, you still need input from users, displaying output, text, all those things. Done in a way which is easy to use. Goal here is to provide a framework to write full applications. Large fraction of mobile devices where their display is a web display. In addition the interface abstract enough in a such, such HTML is, like form elements, accessibility technologies, screen readers, pieces of the modern user interaction picture. Goal is to provide an interface for all of those things. Support interfaces that interface with users.
BB: I have shopped this proposal around and Mozilla. I have conversations with users embed browsers various places. I got feedback which I gave to Hal.
HF: Its a link in the paper.
BB: I can give a high level feedback to group.
RO: Please do.
BB: Trying to make (mozilla) browser embedded. Similar to android’s web view. Basically the people tell me its tricky. A lot of the complexity of the interaction of the web content and the environment. The surface is non-trivial. As evidence by some of the embedded frameworks. Chromium embedded frame work and electron. A lot of complexity there. A particular area that is complicated is security concerns. Spectre in last year, is to run untrusted code in its own process. We must allow in separations to avoid concerns. Modern browsers are moving to a web platform is a multi process thing. Each page is a process. Means harder to interact with multi processes.
JF: We brought up security in general. As long as the API are synchronous, that hide some of the processes.
BB: More general piece of feedback, more disruptions in this space have fairly often. Locking in a design in the standard in a 3 year release cycle might be premature. As brower’s usually have 6 week release schedules. Security fixes all the time. If have a standard library vendor shipping a browser will have to stay up to date which won’t be easy.
RO: P0267 is very much low level. Not requiring hardware access. If you looking for something richer.. its not clear to me how big the intersection is between the two. I don’t see any reason why we don’t want both to go forward in general. Their are constraints of time and effort. How many things can you write an example in web view and graphics. There is a lot of graphics space that this won’t cover very well.
RR: The difficulty between web and c++ (html) - how do I get input, on c++ side. Shipping data back and forth. It could complicate the API.
TH: I would like to respond to security concerns, but people would like to sell their products. Where would web assembly fit into this ? Compile into assembly and place in browser ? Does that fit in here.
JF: I don’t think its relevant. Concerns are deployment of c++ code. Like dynamic linking, etc. That space is still being explored. Web assembly supports modules. But this is separate. I don’t think we need to consider web assembly. In response to RR, in a high level, we should look at various platforms and what they provide. Some as done stuff. Mozilla has disentangling the access given developers, that hindered the out of process development. Took years to move out. Hindered the platform. Given access to users the DOM, should think twice about. If you have a website with an app. I don’t want the c++ to have access to that code. I assume some platforms have dealt with this problem already and thought about the space. What has been done in this space. This is really hard like what BB said.
BB: I am going to take my Mozilla hat off. When it comes to security concerns one reason they may not be as problem - is that this platform is using the web platform technologies, not to browse the web, provide technology as you are running own code.
JF: I will disagree. I used to work on Chrome, and then on Safari. The way its used the app does stuff. Then leads to proper web view. Then it wants to share. Payments. Most webs don’t use payments. They don’t do it natively. They will go to a web page and use the certified by visa app. I care about security.
BB: That is an example of loaded content out there. There is other applications that don’t even hit servers, all local for rendering etc.
JF: But these apps use web view like things.
BB: To have a web view API that doesn’t actually allow use to use OS network stack. Possibility of accessing untrusted contact, what remains is rendering for example.
HF: First I came up with this is minimal. I did this by looking at current APIs. Chrome, web kit, getgo, Microsoft’s Explorer, what is the common subset of these interfaces. My presumption is browser is running in separate process. Many APIs provide DOM model. Wasn’t clear to be if it would be fruitful. Would have to devolve into RPC. Even though IE has this, because ll of there access go though DOM. That wasn’t in the common subset. And having lots of find grained interprocess messages might not work in creating a responsive application. I tried to construct a common interface. This is essentially the interface implemented. QT and WSWidgets, that wrap these implementations. Two other things. In this proposed interface .. there is a way to install the handler let you write your own URI scheme. Files, etc. Supports Get and Post request. I have a way to inject java script. Communication mechanism. You can inject commands to do stuff. Other way is by request. My assumption it was running in a different process. As far as constructing a minimal subset, I don’t have a road map ,accepting whatever feedback I get. Restrict the only process provided scheme, proposed by BB, seems very reasonable to add.
AP: I am quite secure some groups want to see security.
HF: I don’t think we can, due to external process.
AP: Perhaps integration of event loop. I am worried web view How many years browsers have web view. Can we rely on this little scale ?
HF: 15 years ?
AP: Could take 6 years ? At that point will it be useful. Can it be made more useful, something closer to more useful. Like desktop user interface, drawing forms, etc. Perhaps. I am afraid the scope of this paper will be outdated in 10 years.
RR: Underlying does everything though IPC. Thinking of that of a performance considering isn’t an issue anymore.
BB: I just realized earlier about feedback from Mozilla, I didn’t give a conclusion, I heard most people suggest, instead of standardize a web view per se, in parallel another group working on packing, perhaps have web view providers a packing API designed by various web platform vendor. They are updated at the platform update pace for them. Expose that to c++ standards committee. Perhaps this could address AP concern, are these packages going to be around in 10 years.
RO: We are 15 minutes from lunch and we need to draw what we are going to do next.
RR: I ill be in package session tonight. BB you conclusion there is make a library, etc. Same argument as before. We need a library to get feedback that isn’t subject to standard restrictions.
HF: There are other options in the space. One potential direction is provide a lighter weight - and perhaps like network proposal, but provide enough to build out an embedded server, interface with content, rendering, etc. I have not explored. But its reasonable to explore. The other thing is to (follow up on other comments) web view been around for many years - I was working to this, we have a lot of web view development, I don’t think its going away, I think the real thing here, lets say we update the standard every 3 years, very interesting question, is this something we can do ? Do they exist ? External standards exist ? On the issue of external platform package rendering descriptions, I understand the issue about scoping. Its the only standards we can reference. In the paper I talk about other examples. QT has QML. If we want to go down that road we need to standardize. There are other things in this space that we might want to discuss.
RO: This and graphics are not even related, to me. I have not heard anything to indicate differently. Focusing on different things.
BB: I would like to explain they might be related. One set of concerns with 2D graphics this might not be right forum to get the expertise in one place to standardize a graphics API that meets the quality bars of c++ and a related concern of standing a new graphics API when there are others out there, may not be best use of committee time. Having web view out there, can help us to build a graphics 2D inside their own web view. Use web view as a layer to achieve 2D layer on graphics.
RO: You are not using c++.
HF: Java script.
MM: All this is - effectively an interface to a browser, html, web css, open GL, java script, all of which you need to knowledge to use this. We are putting a browser into c++ ? Its very different that what I have been working on.
TH: You could use graphics 2D to write a browser.
MM: Yes.
JF: No browser vender would ever use this. Ask them.
BB: One of which I asked them, would they use this, is would they use this, is the answer is no. They would never use this.
TH: I said they would.
MW: I said they could not would.
MM: That is the answer now, but in the future we don’t know.
RO: We need a target to use cases. I would like to see similar thing from Hal’s paper. Target audiences and use cases. Maybe some overlap may not be. Security comes up. We need to understand the appetite in this room and continued work on these proposals. Is it work Hal going back and working on the proposal. It also a different proposal, earlier stage proposal. Does it make sense to go to Boost or something else, not sure, might be work exploring. Those are decent questions to poll.
TH: Do we want to see this again or not come back. Stay away or do what ever you want.
MW: I need to know about 2D graphics. Multiple times said different things, LEWG said come back, we will have it as a TS after this and this is done. Now it was killed Rapperswill evening session. NB saying we want to revive and keep going. It would help to me if we could get a sense of the room.
RO: David you on mute.
DL: I was wondering what next steps are after this meeting. I am wondering what people think about that. Offline, etc. Do we want to keep talking about this ? Is that something people are interested in ?
RO: I am not sure about slack. Its new to me. My feeling is start with a mailing list and go from there.
MS: The question do we ever we want to see this again. Its not the question I am thinking. What I really like is to have this go into Boost. Get some experience with others outside the committee. Using it the scale we like, production system, teaching a course, etc. Something like that. When there is that, then the experience is good.
RO: Web view stuff ?
MS: I thought this was 2D library conversation.
RO: I was thinking web view.
MS: I would very amenable to see it here after Boost. I am less interested in seeing it again if it doesn’t go into Boost.
RO: TS makes sense also.
MS: At Symantec we can’t use TS, but can use Boost.
MS: I would like to see it in Boost.
MM: Its packaged already.
RO: A package for Kona ? Or Boost ?
MS: Useable for real projects only.
TD: Can you mention where does it exist which platforms ?
MM: WIndows, Mac OS X Coco, X Windows, Linux.
TD: and Feedback from users yet or do you have users ?
MM: No, wasn’t written to be high performance. All of us on our dime working on proposal and reference implementation. A lot of features don’t have reference implementation, given how large it really is now.
TD: Maybe its a special case. New container for example make sense. But this, crucial part of success is vendors providing their own implementation. You are not a vendor. Boost model doesn’t work here.
TH: Doesn’t stop other papers?
RO: Yes, this specific paper. Resolving questions have been raised about this paper.
Poll 1. P0267 - worth spending time working on issues brought up.
- For: 8
- Neutral: 4
- Against: 1
Poll 2. Web View: worth spending time working on.
- For: 7
- Neutral: 4
- Against: 2