Add support for JSON schemas included by URI #247

Open
nilclass opened this Issue Feb 7, 2013 · 8 comments

3 participants

@nilclass
remotestorage member

BaseClient#declareType should support a URI as its schema parameter. That way the schema can be kept in a separate file than the module and possibly included from a public location.

@skddc
remotestorage member

External schemas should still be included inline after the build process, so that we don't impose additional requests for that.

I was actually talking about making usage of schema definition files the standard required way of doing things, not some optional parameter. If that's the case, it can be used with naming conventions and doesn't require a URI parameter.

@skddc
remotestorage member

Also, it would be much better to have all of the "core-approved" production-ready data types in a single directory in the same repo, not scattered around GitHub in module repos. As I said elsewhere, most of the time you don't even need any special module or module-specific functions – instead the schema is the most important definition for a category.

@michielbdejong
remotestorage member

superseded by #661

@skddc skddc reopened this May 13, 2014
@skddc
remotestorage member

I think you misunderstood this one. It's not about custom context URIs, but about loading the whole JSON schema from an arbitrary (or predefined) URI (or file).

@michielbdejong
remotestorage member

What we could do is pull in the schema from its URI during the build. That way it doesn't always have to be accessible at runtime, and doesn't need CORS headers either. The advantage would be that the build would fail if you didn't publish or update the schema on its URL.

The downside would be that it would require building modules. Now, choosing modules is as easy as including or not including their files, and I think we should keep that.

Another option would be to add a build script to the modules repo that builds the specs, so that we can easily publish them. I'll open a ticket for that.

Other than that, I think the declareType syntax is good the way it is now. Can you describe how you would like to change it?

@michielbdejong
remotestorage member

opened remotestorage/modules#36 in relation to this

@skddc
remotestorage member

Why don't we already have to build modules when they use random functional modules?! In the long run, there's no way around a build process for any sufficiently complex JavaScript codebase, and including random files instead of just one (the module build) doesn't make a whole lot of sense for both users and core developers. The outcome I'd predict is that people just include everything they can in order to prevent dependency issues.

I think we should never put the burden of manual dependency management on people!

@skddc
remotestorage member

Other than that, I think the declareType syntax is good the way it is now. Can you describe how you would like to change it?

It's already described in this issue. It is not nice to even need to use this and hide your schema in a module file instead of just having a directory of schema files (or schema files along module files in their folders or sth), which would also enable us to publish these schemas on their respective context URIs. Also, as described above, it would enable us to load schemas from anywhere during build.

@skddc skddc removed this from the Backlog milestone Mar 19, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment