Skip to content

Commit

Permalink
Update report.json, rec-track-repos.json, hr-repos.json
Browse files Browse the repository at this point in the history
  • Loading branch information
w3c-validate-repos-bot committed Nov 2, 2024
1 parent 32f449c commit f8e234d
Showing 1 changed file with 88 additions and 3 deletions.
91 changes: 88 additions & 3 deletions report.json
View file
Original file line number Diff line number Diff line change
Expand Up @@ -3819,6 +3819,7 @@
"w3c/wot-ejs",
"w3c/wot-jp-cg",
"w3c/wot-marketing",
"w3c/wot-ngsi-ld",
"w3c/wot-profile",
"w3c/wot-resources",
"w3c/wot-scripting-api",
Expand Down Expand Up @@ -9894,7 +9895,7 @@
}
]
},
"timestamp": "2024-11-01T00:23:58.498Z",
"timestamp": "2024-11-02T00:25:10.033Z",
"repos": [
{
"id": "MDEwOlJlcG9zaXRvcnk4MTAyMTg2MA==",
Expand Down Expand Up @@ -145748,6 +145749,84 @@
]
}
},
{
"id": "R_kgDONI6ssQ",
"name": "wot-ngsi-ld",
"owner": {
"login": "w3c"
},
"isArchived": false,
"homepageUrl": null,
"description": "work area for the liaison between WoT and ETSI ISG CIM on NGSI-LD",
"isPrivate": false,
"createdAt": "2024-11-01T07:14:20Z",
"labels": [
{
"name": "bug",
"color": "d73a4a"
},
{
"name": "documentation",
"color": "0075ca"
},
{
"name": "duplicate",
"color": "cfd3d7"
},
{
"name": "enhancement",
"color": "a2eeef"
},
{
"name": "good first issue",
"color": "7057ff"
},
{
"name": "help wanted",
"color": "008672"
},
{
"name": "invalid",
"color": "e4e669"
},
{
"name": "question",
"color": "d876e3"
},
{
"name": "wontfix",
"color": "ffffff"
}
],
"defaultBranch": {
"name": "main"
},
"branchProtectionRules": {
"nodes": []
},
"w3cjson": {
"text": "{\n \"group\": 75874\n , \"contacts\": [\"ashimura\"]\n , \"policy\": \"open\"\n , \"repo-type\": [ \"homepage\" ]\n}\n"
},
"prpreviewjson": null,
"autoPublish": null,
"travis": null,
"contributing": null,
"license": null,
"codeOfConduct": null,
"readme": {
"text": "# wot-ngsi-ld\nwork area for the liaison between WoT and ETSI ISG CIM on NGSI-LD\n"
},
"w3c": {
"group": 75874,
"contacts": [
"ashimura"
],
"policy": "open",
"repo-type": [
"homepage"
]
}
},
{
"id": "MDEwOlJlcG9zaXRvcnkyMDUwNDMzMzI=",
"name": "wot-profile",
Expand Down Expand Up @@ -161637,7 +161716,7 @@
"body": "Please find the code of conduct at https://github.com/WebAssembly/meetings/blob/main/CODE_OF_CONDUCT.md.\n"
},
"readme": {
"text": "# WASI-GFX\n\nA proposed [WebAssembly System Interface](https://github.com/WebAssembly/WASI) API.\n\n### Current Phase\n\nPhase 1\n\n### Champions\n\n- Mendy Berger\n- Sean Isom \n\n### Portability Criteria\n\n| | Linux | Window | MacOS | Android | Web |\n| -------- | ----- | ------ | ----- | ------- | --- |\n| Wasmtime | ✅ | ✅ | ✅ | ✅ | |\n| Jco | | | | | ✅ |\n\n## Table of Contents [if the explainer is longer than one printed page]\n\n- [Introduction](#introduction)\n- [Goals [or Motivating Use Cases, or Scenarios]](#goals-or-motivating-use-cases-or-scenarios)\n- [Non-goals](#non-goals)\n- [API walk-through](#api-walk-through)\n - [Use case 1](#use-case-1)\n - [Use case 2](#use-case-2)\n- [Detailed design discussion](#detailed-design-discussion)\n - [[Tricky design choice 1]](#tricky-design-choice-1)\n - [[Tricky design choice 2]](#tricky-design-choice-2)\n- [Considered alternatives](#considered-alternatives)\n - [[Alternative 1]](#alternative-1)\n - [[Alternative 2]](#alternative-2)\n- [Stakeholder Interest & Feedback](#stakeholder-interest--feedback)\n- [References & acknowledgements](#references--acknowledgements)\n\n### Introduction\n\nThis proposal is a collection of multiple packages.\n\n| Package | Description |\n| ------------------------| ---------------------------------------------------------------------------------- |\n| `wasi:webgpu` | WebGPU package for interacting with GPUs |\n| `wasi:frame-buffer` | A CPU based graphics API |\n| `wasi:surface` | A surface |\n| `wasi:graphics-context` | A small interface connecting the graphics APIs (webgpu or frame-buffer) to surface |\n\n\n### Goals [or Motivating Use Cases, or Scenarios]\n\n- Bring some of the benefits that Wasm provides to CPU code, over to GPU code. \n- Enable secure GPU compute.\n- Enable wasm-based UI applications.\n- Enable wasm-based graphics even in environments with no GPUs.\n- Enable wasm-based AI for cases not covered by wasi-nn.\n\n### Non-goals\n\n- A full windowing API.\n- VR/AR (subject to change, if we find contributors with expertise in the field).\n\n### API walk-through\n\nThe full API documentation can be found in [imports.md](imports.md).\n\n#### `wasi:webgpu`\n\n`wasi:webgpu` is based on the official [webgpu spec](https://www.w3.org/TR/webgpu/).\n\n`wasi:webgpu` does deviate sometimes from the webgpu spec, namely, in cases where the spec makes assumptions about running in a web or JS environment. Wherever `wasi:webgpu` deviates from the spec, a clear explanation should be documented.\n\n#### `wasi:surface`\n\n`wasi:surface` is a basic surface API. It lets you create a surface you can draw to (similar to canvas on web). You can also get basic user events from the surface, like pointer and keyboard events.\n\n`wasi:surface` supports the following event types:\n- Pointer: For mouse/touch/pencil/etc.\n- Key: For keyboard events.\n- Resize: Surface was resized.\n- Frame: Fires on each frame. (similar to [`requestAnimationFrame`](https://developer.mozilla.org/en-US/docs/Web/API/window/requestAnimationFrame) on the web)\n\nOther user input, such as scroll wheel, clipboard, drag-over, device motion, device orientation, gamepad input, etc., are all useful in many applications, but since they're a bit less common, they're out of scope for now. However, they might be added eventually.\n\n#### `wasi:frame-buffer`\n\nA simple frame buffer API for CPU-based rendering.\n\nThis might be especially useful in embedded.\n\n#### `wasi:graphics-context`\n\n`wasi:graphics-context` is the point of connection between a graphics API (`wasi:webgpu`, `wasi:frame-buffer`, future graphics API) to a windowing system (`wasi:surface`, future windowing system). See diagram.\n\n![image](https://github.com/user-attachments/assets/55bcc436-7bcd-4f02-9090-888106b889ef)\n\n`wasi:graphics-context` has a method to get the next frame as an `abstract-buffer`. Abstract buffer's contents can't be read. Instead, the graphics API in use can turn the `abstract-buffer` into something it can make use of. E.g. webgpu is able to turn the buffer into a `GPUTexture`. The runtime can easily, in the background, represent the `abstract-buffer` as a `GPUTexture`, and the conversion would just be a no-op.\n\n#### [Use case 1]\n\n[Provide example code snippets and diagrams explaining how the API would be used to solve the given problem]\n\n#### [Use case 2]\n\n[etc.]\n\n### Detailed design discussion\n\n[This section should mostly refer to the .wit.md file that specifies the API. This section is for any discussion of the choices made in the API which don't make sense to document in the spec file itself.]\n\n#### [Tricky design choice #1]\n\n[Talk through the tradeoffs in coming to the specific design point you want to make.]\n\n```\n// Illustrated with example code.\n```\n\n[This may be an open question, in which case you should link to any active discussion threads.]\n\n#### [Tricky design choice 2]\n\n[etc.]\n\n### Considered alternatives\n\n[This section is not required if you already covered considered alternatives in the design discussion above.]\n\n#### [Alternative 1]\n\n[Describe an alternative which was considered, and why you decided against it.]\n\n#### [Alternative 2]\n\n[etc.]\n\n### Stakeholder Interest & Feedback\n\nTODO before entering Phase 3.\n\n[This should include a list of implementers who have expressed interest in implementing the proposal]\n\n### References & acknowledgements\n\nMany thanks for valuable feedback and advice from:\n\n- [Person 1]\n- [Person 2]\n- [etc.]\n"
"text": "# WASI-GFX\n\nA proposed [WebAssembly System Interface](https://github.com/WebAssembly/WASI) API.\n\n### Current Phase\n\nPhase 2\n\n### Champions\n\n- Mendy Berger\n- Sean Isom \n\n### Portability Criteria\n\nLinux, Window, MacOS, Android, Web.\n\n## Table of Contents [if the explainer is longer than one printed page]\n\n- [Introduction](#introduction)\n- [Goals [or Motivating Use Cases, or Scenarios]](#goals-or-motivating-use-cases-or-scenarios)\n- [Non-goals](#non-goals)\n- [API walk-through](#api-walk-through)\n - [Use case 1](#use-case-1)\n - [Use case 2](#use-case-2)\n- [Detailed design discussion](#detailed-design-discussion)\n - [[Tricky design choice 1]](#tricky-design-choice-1)\n - [[Tricky design choice 2]](#tricky-design-choice-2)\n- [Considered alternatives](#considered-alternatives)\n - [[Alternative 1]](#alternative-1)\n - [[Alternative 2]](#alternative-2)\n- [Stakeholder Interest & Feedback](#stakeholder-interest--feedback)\n- [References & acknowledgements](#references--acknowledgements)\n\n### Introduction\n\nThis proposal is a collection of multiple packages.\n\n| Package | Description |\n| ------------------------| ---------------------------------------------------------------------------------- |\n| `wasi:webgpu` | WebGPU package for interacting with GPUs |\n| `wasi:frame-buffer` | A CPU based graphics API |\n| `wasi:surface` | A surface |\n| `wasi:graphics-context` | A small interface connecting the graphics APIs (webgpu or frame-buffer) to surface |\n\n\n### Goals [or Motivating Use Cases, or Scenarios]\n\n- Bring some of the benefits that Wasm provides to CPU code, over to GPU code. \n- Enable secure GPU compute.\n- Enable wasm-based UI applications.\n- Enable wasm-based graphics even in environments with no GPUs.\n- Enable wasm-based AI for cases not covered by wasi-nn.\n\n### Non-goals\n\n- A full windowing API.\n- VR/AR (subject to change, if we find contributors with expertise in the field).\n\n### API walk-through\n\nThe full API documentation can be found in [imports.md](imports.md).\n\n#### `wasi:webgpu`\n\n`wasi:webgpu` is based on the official [webgpu spec](https://www.w3.org/TR/webgpu/).\n\n`wasi:webgpu` does deviate sometimes from the webgpu spec, namely, in cases where the spec makes assumptions about running in a web or JS environment. Wherever `wasi:webgpu` deviates from the spec, a clear explanation should be documented.\n\n#### `wasi:surface`\n\n`wasi:surface` is a basic surface API. It lets you create a surface you can draw to (similar to canvas on web). You can also get basic user events from the surface, like pointer and keyboard events.\n\n`wasi:surface` supports the following event types:\n- Pointer: For mouse/touch/pencil/etc.\n- Key: For keyboard events.\n- Resize: Surface was resized.\n- Frame: Fires on each frame. (similar to [`requestAnimationFrame`](https://developer.mozilla.org/en-US/docs/Web/API/window/requestAnimationFrame) on the web)\n\nOther user input, such as scroll wheel, clipboard, drag-over, device motion, device orientation, gamepad input, etc., are all useful in many applications, but since they're a bit less common, they're out of scope for now. However, they might be added eventually.\n\n#### `wasi:frame-buffer`\n\nA simple frame buffer API for CPU-based rendering.\n\nThis might be especially useful in embedded.\n\n#### `wasi:graphics-context`\n\n`wasi:graphics-context` is the point of connection between a graphics API (`wasi:webgpu`, `wasi:frame-buffer`, future graphics API) to a windowing system (`wasi:surface`, future windowing system). See diagram.\n\n![image](https://github.com/user-attachments/assets/55bcc436-7bcd-4f02-9090-888106b889ef)\n\n`wasi:graphics-context` has a method to get the next frame as an `abstract-buffer`. Abstract buffer's contents can't be read. Instead, the graphics API in use can turn the `abstract-buffer` into something it can make use of. E.g. webgpu is able to turn the buffer into a `GPUTexture`. The runtime can easily, in the background, represent the `abstract-buffer` as a `GPUTexture`, and the conversion would just be a no-op.\n\n#### [Use case 1]\n\n[Provide example code snippets and diagrams explaining how the API would be used to solve the given problem]\n\n#### [Use case 2]\n\n[etc.]\n\n### Detailed design discussion\n\n[This section should mostly refer to the .wit.md file that specifies the API. This section is for any discussion of the choices made in the API which don't make sense to document in the spec file itself.]\n\n#### [Tricky design choice #1]\n\n[Talk through the tradeoffs in coming to the specific design point you want to make.]\n\n```\n// Illustrated with example code.\n```\n\n[This may be an open question, in which case you should link to any active discussion threads.]\n\n#### [Tricky design choice 2]\n\n[etc.]\n\n### Considered alternatives\n\n[This section is not required if you already covered considered alternatives in the design discussion above.]\n\n#### [Alternative 1]\n\n[Describe an alternative which was considered, and why you decided against it.]\n\n#### [Alternative 2]\n\n[etc.]\n\n### Stakeholder Interest & Feedback\n\nTODO before entering Phase 3.\n\n[This should include a list of implementers who have expressed interest in implementing the proposal]\n\n### References & acknowledgements\n\nMany thanks for valuable feedback and advice from:\n\n- [Person 1]\n- [Person 2]\n- [etc.]\n"
}
},
{
Expand Down Expand Up @@ -161836,7 +161915,9 @@
"autoPublish": null,
"travis": null,
"contributing": null,
"license": null,
"license": {
"text": "Copyright © 2019-2024 the Contributors to the WASI Specification, published\nby the [WebAssembly Community Group][cg] under the\n[W3C Community Contributor License Agreement (CLA)][cla]. A human-readable\n[summary][summary] is available.\n\n[cg]: https://www.w3.org/community/webassembly/\n[cla]: https://www.w3.org/community/about/agreements/cla/\n[summary]: https://www.w3.org/community/about/agreements/cla-deed/\n"
},
"codeOfConduct": {
"body": "Please find the code of conduct at https://github.com/WebAssembly/meetings/blob/main/CODE_OF_CONDUCT.md.\n"
},
Expand Down Expand Up @@ -191243,6 +191324,10 @@
"name": "wot-marketing",
"fullName": "w3c/wot-marketing"
},
{
"name": "wot-ngsi-ld",
"fullName": "w3c/wot-ngsi-ld"
},
{
"name": "wot-testing",
"fullName": "w3c/wot-testing"
Expand Down

0 comments on commit f8e234d

Please sign in to comment.