Empathy List Archives

P

Parkinbot

Tue, Mar 29, 2016 12:27 AM

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.

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

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. -- View this message in context: http://forum.openscad.org/Idea-include-use-a-remote-scad-tp16760p16782.html Sent from the OpenSCAD mailing list archive at Nabble.com.

MK

Marius Kintel

Tue, Mar 29, 2016 1:40 AM

On Mar 28, 2016, at 19:09 PM, doug moen doug@moens.org 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

> On Mar 28, 2016, at 19:09 PM, doug moen <doug@moens.org> 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

MK

Marius Kintel

Tue, Mar 29, 2016 1:44 AM

On Mar 28, 2016, at 19:25 PM, Torsten Paul Torsten.Paul@gmx.de 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

> On Mar 28, 2016, at 19:25 PM, Torsten Paul <Torsten.Paul@gmx.de> 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

TP

Torsten Paul

Tue, Mar 29, 2016 11:40 AM

Von: "Marius Kintel" marius@kintel.net

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.

Von: "Marius Kintel" <marius@kintel.net> > > 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.

MK

Marius Kintel

Tue, Mar 29, 2016 1:20 PM

On Mar 29, 2016, at 07:40 AM, Torsten Paul Torsten.Paul@gmx.de 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

> On Mar 29, 2016, at 07:40 AM, Torsten Paul <Torsten.Paul@gmx.de> 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

T

TLC123

Sat, Jul 22, 2017 2:11 PM

Was this the last on the issue or did the discussion move?

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

Was this the last on the issue or did the discussion move? -- View this message in context: http://forum.openscad.org/Idea-include-use-a-remote-scad-tp16760p21902.html Sent from the OpenSCAD mailing list archive at Nabble.com.

discuss@lists.openscad.org

Idea: include/use a remote .scad