aframevr / aframe-registry Goto Github PK

@donmccurdy @fernandojsg

What I'm considering, since it's a lot of overhead to curate every component and tie each version to a component, and even when we do they're broken anyways. We don't have the time or manpower to act as full time code reviewers.

Have the Registry act as an index rather than a curated store, for a place for people to find every single component (perhaps showing the "good" ones up top). If they don't work, they can go file an issue, or copy/paste the code and modify it. And we can show application-specific components for inspiration (A-Blast, A-Painter). Then we can say "here's literally every single possible feature"

Showcased applications like A-Blast or A-Painter can have their own pages so people can see what components were used to make them.

I've heard Unity Store components are often broken as well, so there's precedent :)

I would like to load point clouds in a-frame. is this the right place to implement and commit? willing to write it.

is there another components that makes sense to adapt?

If I do an npm version patch bump to a component, do I also need to submit a PR here? If the component URL includes a SHA1, I assume that a PR would be necessary.

Is it possible to update this repository automatically (after an initial PR to register the component) using NPM APIs and looking for an aframe subtree in package.json?

With a list of components and URLs, we could later build a frontend to bundle together selected components.

Bootstrap Customizer
jQuery UI Builder

Copy the URL + script tag on https://aframe.io/aframe-registry/ next to the download and github link, could use e.g. https://clipboardjs.com with its icon.

Currently metadata parsing will scrape HTTP or HTTPS images, and https://aframe.io/aframe-registry/ throws Mixed Content warnings as a result.

Before I start adding shaders, just gonna add unit tests because there're a lot of moving parts and policies with clear inputs and outputs.

We could perhaps cross this road later once we consider support, but good to get feedback. This is easier than managing different aspects of a package across different keys.

Current:

components:
  aframe-physics:
    names: body, joint

to:

aframe-physics:
  components: body, joint
  systems: physics
  primitives: a-newtons-cradle

@dmarcos and @donmccurdy and I met for roadmap and priorities. Generally, we don't want to have a curation bar, and just show everything. With or without extra/scraped metadata. There are also currently multiple ways to find components (npm, awesome, Google, docs), so there is duplicated effort here. Options:

1. Discontinue the Registry, link to npm search instead (or other search engines).
2. Automate and index npm to do a pretty display of components with images and search.

Feedback needed! Does your life depend on the Registry? Let us know.

If a component specifies dependency components (on other components in the Registry):

• The Inspector will install the dependency components before the main component.
• angle will install the dependency components before the main component.

This will allow for components to build on top of each other (e.g., a component can use animations).

We're no longer using https://github.com/aframevr/aframe-shaders so we could close that repo and add another entry here to store the community shaders.

I just tested a couple from the A-Frame homepage:

• leap-hands
• audio-analyzer
• firebase
• firebase-broadcast
• json-model
• mountain

(items crossed out are now fixed)

That leap-hands is broken is my own fault; I ignored the dist folder in .npmignore. The others seem to have various issues, some missing on NPM, some throwing JavaScript errors.

Not sure how feasible it would be to test entries in an automated way.

Would be nice to be able to link to URLs like:

• /tagged/controls
• /tagged/loaders
• /tagged/animation

Should the registry be maintained as YAML or JSON?

YAML is indent-based and cleaner to read (without all the double-quotes). Might make it marginally easier to maintain.

Either way, we will still have a build step and still output to JSON.

http://lab.immersiveweb.ch is requesting your username and password. WARNING: Your password will not be sent to the website you are currently visiting!

Following the discussion we had (@dmarcos, @ngokevin) about it last week...

The current structure is:

{
  "collider" : {
    "author": "Diego Marcos",
    "description": "Triggers events when object collide",
    "url": "https://rawgit.com/dmarcos/a-invaders/31f5a7/js/components/collider.js"
  },
  "explode" : {
    "author": "Diego Marcos",
    "description": "Makes the geometry explode",
    "url": "https://rawgit.com/dmarcos/a-invaders/31f5a7/js/components/explode.js"
  },
  "spawner" : {
    "author": "Diego Marcos",
    "description": "Spawns an entity on an event",
    "url": "https://rawgit.com/dmarcos/a-invaders/31f5a7/js/components/spawner.js"
  }
}

Add some new parameters:

• help_url: (optional) It will be used in the help button next to the inspector's sidebar.
• screenshot_url: (optional) It will be shown in component list in the "add new component" modal dialog.
• url: (mandatory) pairs of version and url: {"0.3.0": "http://blabla", "0.4.0": "http://blabla4"}
• schema_grouping: (optional): If defined it will be used to group and sort the parameters on the inspector UI as proposed on aframevr/aframe-inspector#303. We could even force to hide the parameters from the schema not defined in this grouping, we could get easily get rid of parameters like mergeTo or similar.

With the changes proposed the JSON could looks like the following:

{
  "collider": {
    "author": "Diego Marcos",
    "description": "Triggers events when object collide",
    "url": {
      "0.3.0": "http://blabla",
      "0.4.0": "http://blabla4"
    },
    "help_url": "http://helpurl",
    "screenshot_url": "http://screenshot.png",
    "schema_grouping": [
      {
        "name": "size",
        "attributes": [
          "width",
          "height",
          "width"
        ]
      },
      {
        "name": "segments",
        "attributes": [
          "segmentwidth",
          "segmentheight",
          "segmentwidth"
        ]
      }
    ]
  },
  "explode": {
    "author": "Diego Marcos",
    "description": "Makes the geometry explode",
    "url": {
      "0.3.0": "http://blabla"
    },
    "help_url": "http://helpurl"
  },
  "spawner": {
    "author": "Diego Marcos",
    "description": "Spawns an entity on an event",
    "url": {
      "0.3.0": "http://blabla"
    }
  }
}

We've discussed ordering, grouping, sorting of A-Frame component properties for display in the Inspector.

• Should that live in the component or registry?
• Format of the Inspector-specific metadata?

Within the component sounds easiest, but I'm a little worried it couples the component to the Inspector. Putting the metadata elsewhere for purely display purposes seems technically cleaner in terms of abstraction.

https://github.com/ngokevin/aframe-physics-components/blob/master/dist/aframe-physics-components.js

This physics component is bundled up with physics-body and physics-world. They are coupled and are bundled with cannon.js.

It makes aframe look dead. Just turn it into the equivalent of a subreddit if nothing else. Preferably make it a wiki so the community can maintain it. Almost anything would be better than it sitting here as a monument to 2016/2017. A month into an A-frame project, I still can't shake the feeling that aframe is dying because almost every example I look up is old, and this created that strong first impression.

aframevr/aframe-inspector#495

As every time we deploy a new version of aframe we forget to generate and publish a new version of the registry and the inspector keep showing an error that the newest version can't be loaded :)

It seems like the inspector is looking for the component registry at: https://aframe.io/aframe-registry/build/0.7.0.json. This is sending a 404 error back and preventing the inspector from opening.

A common workflow I have is I know a component I want, and want to grab the latest unpkg build. Normally, I type in the url unpkg.com/<npmName>/, and go through the index directory, and find the JS file to copy the link of.

I want to add a separate page that just has a search box. In the search box, you type in component names or component npm names. A list will populate providing minified JS files from unpkg.com.

e.g., Search: [log]

[Copy] https://unpkg.com/[email protected]/dist/aframe-log-component.min.js
[Copy] https://unpkg.com/[email protected]/dist/aframe-log-component.min.js
[Copy] https://unpkg.com/[email protected]/dist/aframe-log-component.min.js

It could live on like aframe.io/registry/search with a section for unpkg.

If you have a component you want to see, comment here. Ideally, describe what the component would do and which properties you'd like to see the component have.

Would be nice to gather a list of all the <a-> primitives since those are easy to use and to encourage authors to abstract their components even further.

package:
  versions: 
    0.4.0: 
       version: x.x.x
       path: blahblah

package:
  path: blahblah
  versions: 
    0.4.0: 
       version: x.x.x

Path can be overridden by a version entry

Currently: https://npmjs/package/aframe-stereo-component
Expected: https://npmjs.com/package/aframe-stereo-component

https://github.com/naugtur/aframe-livereload-image

It's functional already, but I'm hoping to extend it a bit further.

I've removed the link to example because opening it tells you nothing and it generates useless traffic.
Once I add support for livereload based on http headers (if not on file:// protocol) I can create a glitch example site that'd serve a different image every 20 seconds.

But in general, this tool is useful for artists painting straight onto a panorama file.

YAML breaks consistency for a marginal benefit. We use JSON everywhere and introducing something different adds more confusion than help. JSON is already simple enough

Later on, assets/shaders/controls/effects/etc., could live here. It might save us trouble later to name it appropriately now.

aframe-registry is nice since it's agnostic on the type of asset. And aframe-components sounds like the actual components/files live here, rather than just referencing them.

Will start populating with components that would do well from the Inspector (i.e., have an immediate visual effect that don't need to be composed with other components).

• ocean
• particle-system
• physics

There are other great components that function better from code/HTML...we can perhaps add those after.