Hi Runsun,

I don’t think direct URLs to files is the best way forward, but I’d like to offer an automated way of synchronizing with external files/repositories.
As you mention, the key is to allow locking a design to a particular version to avoid pulling in breaking changes later on.

I should write this up as a project on the wiki, but here’s a rough wishlist:
o Support having a project description (either in-line or as a separate file)  holding the links (and versions) of wanted dependencies.
o This project description will list all dependencies, their location, including version number (or e.g. branch if it’s a git link)
o Offer some UI or cmd-line for pulling / synchronizing dependencies
o Host an authoritative online repository of OpenSCAD libraries, components and designs
o Offer UI for discovery/browsing/searching of said online repository
o Allow anyone to publish to the repository their namespace of choice
o Alternative to hosting our own repository: Partner with an existing repository and use their API

Joshua started on this a long while ago: https://github.com/jfhbrook/scadpan

For this to really work, we first need to implement support for basic namespaces in OpenSCAD to avoid external components polluting the global namespace.

-Marius

I think this is a good idea.

I would add some extra URL schemes for github and thingiverse.
For example,
use github://openscad/scad-utils/trajectory.scad
use thingiverse://thing:349943/relativity.scad

The github scheme is easy to implement by text substitution. The
thingiverse scheme needs to be implemented using the thingiverse web API.
If we implement the thingiverse URL scheme, then probably we won't need
support for unpacking a zip file.

It is very important to implement persistent caching for this feature.
Otherwise, popular scad models (perhaps some hosted on thingiverse) could
end up hammering someone's personal web server that hosts popular
libraries. We do not want openscad to be the source of an accidental DOS
attack on someone's server.

We need to support relative URLs. If a model consists of multiple files,
then the main model file should use relative URLs to access the auxiliary
files. That makes the code position independent. If an scad script was
fetched via a remote URL, then any include, use or import statements in
that script will interpret pathnames like "foo.stl" as relative URLs, not
as local file system references.

On 28 March 2016 at 09:44, runsun runsun@gmail.com wrote:

On 03/28/2016 04:50 PM, doug moen wrote:

Yes, and it could also extend to using web fonts directly,
although it seems it's not easily possible to use the google
font repo that way.

I'm not sure we can handle support for various web APIs.
Anytime something changes, it's on our plate to update.

In addition, I'm not sure we can generally handle thingiverse
scad files without trying to emulate their platform. They
have a couple of extra files available which we would need
to infer from the filename and than magically pull those
from somewhere.

Also using the thingiverse API involves registering and
validating the app. They don't require revalidation for
every release like Apple, but still reserve the right to
revoke access any time.

open for authorized users, so we'd need to be able to
login the user for every access.

And there's another issue as the apps need to use a token
(https://www.thingiverse.com/developers/getting-started)
and then send client_id and client_secret. I have no idea
how that can work with an open source app as there is no
way to keep that token secret.

ciao,
Torsten.

@parkinbot: the ver=-1 option in particular will cause a denial-of-service
attack against the target web server. For example, it will force a download
on every frame of an animation.

We must not provide a DOS capability within the OpenSCAD language. Remote
files must be cached, and we can use web browser semantics for
automatically deciding when the cache needs to be refreshed. The mechanism
for forcing the reload of a particular file from a web server needs to be
outside of the language, and must be triggered by an explicit user
interface action.

On 28 March 2016 at 12:09, Parkinbot rudolf@parkinbot.com wrote:

Torsten, you are right, my thingiverse URL scheme won't work without
negotiating some sort of deal with Thingiverse. Maybe they'd be amenable to
a deal, given how they use openscad to run their web site. But the API
terms of service prevent us from using it.

In order to make thingiverse access work properly, we need some way to make
relative URLs work correctly. Runsun's suggestion for zip-file relative
addressing would be the other approach, but I'd want to amend the URL
syntax so that relative URLs work.

On 28 March 2016 at 11:56, Torsten Paul Torsten.Paul@gmx.de wrote:

Marius: Joshua's idea for an official "scadpan" repository is a good one,
if we can put together the resources to set it up and maintain it.

Once we have this repository, we still need some syntax for conveniently
accessing files within the repository. It has to be compatible with
include<>, use<>, import(file=), surface(file=), etc. I suggest an scadpan:
URL scheme. This will allow people to continue to distribute small projects
as single *.scad files, and the instructions for using some new library
will be as simple as "add this one line of code to your *.scad file". If
you need to create a separate project description file just to reference an
external library, then that creates a significant barrier to use.

On 28 March 2016 at 10:32, Marius Kintel marius@kintel.net wrote:

On 03/29/2016 01:02 AM, doug moen wrote:

Well, I guess it won't hurt to ask, but I suspect both the
login and the API token issues are not easily solvable.

They mention that there might be a read-only API somewhere
in the future, but I figure nobody is currently working on
that.

The token issue is more complicated, I don't see any way
around that except if they allow the read-only API to be
used without the token but just with some kind of rate
limiting. Well the other solution would be to have the
token included in OpenSCAD, but that makes it pretty much
useless then as everybody could just impersonate the
OpenSCAD application and per API TOS we'd be the ones to
blame.

I don't see how the ZIP handling in the script itself
would make sense. To get it going you already need a
file that references the ZIP file and the files included
will not reference it either, but maybe I'm just missing
something.

To me it sound like that would be more a job for some
kind of browser that allows to search/explore the things
on thingiverse and allows to open selected things in
OpenSCAD. Probably like the example application they
reference.
(https://github.com/potatono/lets-look-at-your-things)

For single files it would be already much easier if they
could send a useful mime-type instead of just

Content-Type: application/octet-stream

ciao,
Torsten.

Here's how thingiverse URLs could work.

include thingiverse://thing:16193/write.scad

How this works is: we download http://www.thingiverse.com/thing:16193/zip,
then unzip the zip file, and reference the file "write.scad" inside that
zip file.

When write.scad executes
import(file="Letters.dxf", layer=...);
then, since the parent script was referenced via a URL, we interpret
"Letters.dxf" as a relative URL. According to the rules for relative URLs,
we convert this name to its absolute URL form, relative to the parent URL,
which is "thingiverse://thing:16193/Letters.dxf". We've already got this
file in our cache (it's part of the zip file we just downloaded).

On 28 March 2016 at 19:25, Torsten Paul Torsten.Paul@gmx.de wrote: