Idea: include/use a remote .scad

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Idea: include/use a remote .scad

runsun
like:

include <http://.... somefile.scad>
include <ftp://.... somefile.scad>

The benefits:

1) Use a file on the internet/cloud w/o the need for users to download/save;
2) Can always use the most updated version on the net (certainly, this may not always be a plus)

Advanced version to download and unzip and include:

include <http://.... somearchive.zip: somefile.scad>

Let Openscad do the download/save AND unzip

Note:

When browsing thingiverse, I always am annoyed that I can't view the .scad file on the net. I have to download it, unzip it, load it with Openscad, then I can see what's inside to decide if that's what I want. If it's not, then I have to go through the process of locating and deleting all the downloaded files.

This is a very tedious process for something I don't want. Very often I just want to see how people do specific things to decide if I want to download, or simply just want to learn but not keep the files. The way thingiverse works make this very inconvenient (in this day of cloud computing, it feels like 19th-ish century), in such a way that, in many cases, I simply just gave it up.

Although this is not OpenSCAD's issue, having the ability to use/include a remote file using valid URI can be applied to many cases other than thingiverse. For example, github.
$ Runsun Pan, PhD
$ libs:doctest, faces(git), offline doc(git), runscad.py(2,git), synwrite(2);   $ tips:Collection of tips on github
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Idea: include/use a remote .scad

kintel
Administrator
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


> On Mar 28, 2016, at 09:44 AM, runsun <[hidden email]> wrote:
>
> like:
>
> include <http://.... somefile.scad>
> include <ftp://.... somefile.scad>
>
> The benefits:
>
> 1) Use a file on the internet/cloud w/o the need for users to download/save;
> 2) Can always use the most updated version on the net (certainly, this may
> not always be a plus)
>
> Advanced version to download and unzip and include:
>
> include <http://.... somearchive.zip: somefile.scad>
>
> Let Openscad do the download/save AND unzip
>
> Note:
>
> When browsing thingiverse, I always am annoyed that I can't view the .scad
> file on the net. I have to download it, unzip it, load it with Openscad,
> then I can see what's inside to decide if that's what I want. If it's not,
> then I have to go through the process of locating and deleting all the
> downloaded files.
>
> This is a very tedious process for something I don't want. Very often I just
> want to see how people do specific things to decide if I want to download,
> or simply just want to learn but not keep the files. The way thingiverse
> works make this very inconvenient (in this day of cloud computing, it feels
> like 19th-ish century), in such a way that, in many cases, I simply just
> gave it up.
>
> Although this is not OpenSCAD's issue, having the ability to use/include a
> remote file using valid URI can be applied to many cases other than
> thingiverse. For example, github.
>
>
>
> -----
>
> $  Runsun Pan, PhD $ libs: doctest , faces ( git ), offline doc ( git ), runscad.py( 1 , 2 , git ), synwrite( 1 , 2 );  $ tips: hash( 1 , 2 ), matrix( 1 , 2 ),sweep( 1 , 2 ), var( 1 , 2 ), lerp , animation ( gif , prodVid ), precision( 1 , 2 ), xl-control , type , rounded polygon , chfont
>
>
>
>
>
>
> --
> View this message in context: http://forum.openscad.org/Idea-include-use-a-remote-scad-tp16760.html
> Sent from the OpenSCAD mailing list archive at Nabble.com.
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Idea: include/use a remote .scad

doug.moen
In reply to this post by runsun
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 <[hidden email]> wrote:
like:

include <http://.... somefile.scad>
include <ftp://.... somefile.scad>

The benefits:

1) Use a file on the internet/cloud w/o the need for users to download/save;
2) Can always use the most updated version on the net (certainly, this may
not always be a plus)

Advanced version to download and unzip and include:

include <http://.... somearchive.zip: somefile.scad>

Let Openscad do the download/save AND unzip

Note:

When browsing thingiverse, I always am annoyed that I can't view the .scad
file on the net. I have to download it, unzip it, load it with Openscad,
then I can see what's inside to decide if that's what I want. If it's not,
then I have to go through the process of locating and deleting all the
downloaded files.

This is a very tedious process for something I don't want. Very often I just
want to see how people do specific things to decide if I want to download,
or simply just want to learn but not keep the files. The way thingiverse
works make this very inconvenient (in this day of cloud computing, it feels
like 19th-ish century), in such a way that, in many cases, I simply just
gave it up.

Although this is not OpenSCAD's issue, having the ability to use/include a
remote file using valid URI can be applied to many cases other than
thingiverse. For example, github.



-----

$  Runsun Pan, PhD $ libs: doctest , faces ( git ), offline doc ( git ), runscad.py( 1 , 2 , git ), synwrite( 1 , 2 );  $ tips: hash( 1 , 2 ), matrix( 1 , 2 ),sweep( 1 , 2 ), var( 1 , 2 ), lerp , animation ( gif , prodVid ), precision( 1 , 2 ), xl-control , type , rounded polygon , chfont






--
View this message in context: http://forum.openscad.org/Idea-include-use-a-remote-scad-tp16760.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org




_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
tp3
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Idea: include/use a remote .scad

tp3
On 03/28/2016 04:50 PM, doug moen wrote:
> I think this is a good idea.
>
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.

> The github scheme is easy to implement by text substitution.
> The thingiverse scheme needs to be implemented using the
> thingiverse web API.
>
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.

From a short test, it looks like the complete API is only
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.


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
-- Torsten
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Idea: include/use a remote .scad

Parkinbot
In reply to this post by kintel
Why not offer a inet_libaries folder where downloaded files are cached with some hashbased naming scheme similar to the backups folder. Enforcement to download a newer version could be done implicitly session-based or explicitly by a "renew" switch. It could also be used to enforce freezing to a current version or two maintain and use different versions of the same library - in different sketches.

import ("http://.../somefile.scad", renew = ver);   // ver is cached version order.

ver=0 (default): enforce download on a session base and use latest version in cache.
ver=n use version n if in cache, otherwise use ver=0
ver=-1 enforce immediate download and use ver=0

(Unqualified) name resolving can use a defined order with origin optionally being echoed to console:
1. current folder of main scad file
2. libraries folder
3. inet_libraries folder
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Idea: include/use a remote .scad

doug.moen
@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 <[hidden email]> wrote:
Why not offer a inet_libaries folder where downloaded files are cached with
some hashbased naming scheme similar to the backups folder. Enforcement to
download a newer version could be done implicitly session-based or
explicitly by a "renew" switch. It could also be used to enforce freezing to
a current version or two maintain and use different versions of the same
library - in different sketches.

import ("http://.../somefile.scad", renew = ver);   // ver is cached version
order.

ver=0 (default): enforce download on a session base and use latest version
in cache.
ver=n use version n if in cache, otherwise use ver=0
ver=-1 enforce immediate download and use ver=0

(Unqualified) name resolving can use a defined order with origin optionally
being echoed to console:
1. current folder of main scad file
2. libraries folder
3. inet_libraries folder



--
View this message in context: http://forum.openscad.org/Idea-include-use-a-remote-scad-tp16760p16767.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org




_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Idea: include/use a remote .scad

doug.moen
In reply to this post by tp3
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 <[hidden email]> wrote:
On 03/28/2016 04:50 PM, doug moen wrote:
> I think this is a good idea.
>
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.

> The github scheme is easy to implement by text substitution.
> The thingiverse scheme needs to be implemented using the
> thingiverse web API.
>
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.

From a short test, it looks like the complete API is only
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.


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org




_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Idea: include/use a remote .scad

doug.moen
In reply to this post by kintel
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 <[hidden email]> wrote:
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


> On Mar 28, 2016, at 09:44 AM, runsun <[hidden email]> wrote:
>
> like:
>
> include <http://.... somefile.scad>
> include <ftp://.... somefile.scad>
>
> The benefits:
>
> 1) Use a file on the internet/cloud w/o the need for users to download/save;
> 2) Can always use the most updated version on the net (certainly, this may
> not always be a plus)
>
> Advanced version to download and unzip and include:
>
> include <http://.... somearchive.zip: somefile.scad>
>
> Let Openscad do the download/save AND unzip
>
> Note:
>
> When browsing thingiverse, I always am annoyed that I can't view the .scad
> file on the net. I have to download it, unzip it, load it with Openscad,
> then I can see what's inside to decide if that's what I want. If it's not,
> then I have to go through the process of locating and deleting all the
> downloaded files.
>
> This is a very tedious process for something I don't want. Very often I just
> want to see how people do specific things to decide if I want to download,
> or simply just want to learn but not keep the files. The way thingiverse
> works make this very inconvenient (in this day of cloud computing, it feels
> like 19th-ish century), in such a way that, in many cases, I simply just
> gave it up.
>
> Although this is not OpenSCAD's issue, having the ability to use/include a
> remote file using valid URI can be applied to many cases other than
> thingiverse. For example, github.
>
>
>
> -----
>
> $  Runsun Pan, PhD $ libs: doctest , faces ( git ), offline doc ( git ), runscad.py( 1 , 2 , git ), synwrite( 1 , 2 );  $ tips: hash( 1 , 2 ), matrix( 1 , 2 ),sweep( 1 , 2 ), var( 1 , 2 ), lerp , animation ( gif , prodVid ), precision( 1 , 2 ), xl-control , type , rounded polygon , chfont
>
>
>
>
>
>
> --
> View this message in context: http://forum.openscad.org/Idea-include-use-a-remote-scad-tp16760.html
> Sent from the OpenSCAD mailing list archive at Nabble.com.
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
tp3
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Idea: include/use a remote .scad

tp3
In reply to this post by doug.moen
On 03/29/2016 01:02 AM, doug moen 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.
>
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.

> 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.
>
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.


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
-- Torsten
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Idea: include/use a remote .scad

doug.moen
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 <[hidden email]> wrote:
On 03/29/2016 01:02 AM, doug moen 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.
>
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.

> 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.
>
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.


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org




_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Idea: include/use a remote .scad

Parkinbot
In reply to this post by doug.moen
You are right, ver =-1 can get nasty, when used naively (even reloads could be easily limited to F5/F6 range, what I had in mind). If a reload really has to be enforced one can also restart the session.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Idea: include/use a remote .scad

kintel
Administrator
In reply to this post by doug.moen
> On Mar 28, 2016, at 19:09 PM, doug moen <[hidden email]> wrote:
> If you need to create a separate project description file just to reference an external library, then that creates a significant barrier to use.
>
I agree. We need a convenient way of describing that inline.

 -Marius


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Idea: include/use a remote .scad

kintel
Administrator
In reply to this post by tp3
> On Mar 28, 2016, at 19:25 PM, Torsten Paul <[hidden email]> wrote:
>
> They mention that there might be a read-only API somewhere
> in the future, but I figure nobody is currently working on
> that.
>
In the mean-time, we could always offer a read-only (caching?) proxy, and use the token-based API server-to-server.
That would of course require us to tie in OpenSCAD to an official (or configurable) server.
If we were to host an official collection of libraries we’d need that anyway.

 -Marius


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
tp3
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Idea: include/use a remote .scad

tp3
Von: "Marius Kintel" <[hidden email]>

> > They mention that there might be a read-only API somewhere
> > in the future, but I figure nobody is currently working on
> > that.
> >
> In the mean-time, we could always offer a read-only (caching?)
> proxy, and use the token-based API server-to-server.
> That would of course require us to tie in OpenSCAD to an official
> (or configurable) server. If we were to host an official collection
> of libraries we’d need that anyway.
>
Right, if they agree to that, it could work. The user token
should be no issue as we would only see the encrypted data.

It still would have the issue of being an open relay that
might be used by other means than just the OpenSCAD application
but if we only allow access to a limited part of the API and
have some rate limiting, that might be acceptable.

ciao,
  Torsten.

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
-- Torsten
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Idea: include/use a remote .scad

kintel
Administrator
> On Mar 29, 2016, at 07:40 AM, Torsten Paul <[hidden email]> wrote:
> Right, if they agree to that, it could work. The user token
> should be no issue as we would only see the encrypted data.
>

If we use their API and only proxy data with a suitable license, that should be ok I think. Details needs to be discussed..

> It still would have the issue of being an open relay that
> might be used by other means than just the OpenSCAD application

I have a feeling it won’t be that popular ;) Yes, we should cache and/or ratelimit the API.

 -Marius


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Idea: include/use a remote .scad

TLC123
Was this the last on the issue or did the discussion move?
Loading...