Wish: tinyurl about circuitjs1 HOT 12 CLOSED

Alternatively, a load from URL option in the URL might be easy to implement and could leverage existing pastebins.

from circuitjs1.

I've never been keen on "load from URL" because it's a soft-off cross-site scripting situation. What I would like to do one day is to integrate with something like Google Docs for cloud-based file support.

from circuitjs1.

If not load from url, maybe pick a pastebin to support. GoogleDocs comes with a whole bunch of tracking and other issues, a raw pastebin should be much less code to write.

from circuitjs1.

I looked into this but ran into a browser security issue. Our javascript can't access other websites because of the same-origin policy. So you can't use pastebin's api.

One way around that might be to provide an option to store the circuit data in JSONP format. But you'd still have to paste it manually.

I might be willing to provide a server to store the circuits on my website.

from circuitjs1.

On 2016-11-03 01:42, Iain Sharp wrote:

I've never been keen on "load from URL" because it's a soft-off
cross-site scripting situation. What I would like to do one day is to
integrate with something like Google Docs for cloud-based file
support.

I don't like this cloud based approach either. Wouldn't it be easy to
make a small sqllite db on the server which stores something as simple
as "ctime, atime, policy, author, title, *hash, schematic" ( are
indexed).

ctime:
even if schematic files are small, i don't want to put burden
on the servers, tracking a creation date would allow them to be purged
(see policy below).

atime:
track when files are accessed. Instead ctime one could make
policies by atime, then often used files would not become purged. When
write-load on the db matter (I doubt that) atime could be stored only
coarsely, per hour or so.

policy:
could be actually more fields. Something like a time to live, per
ctime and per atime. also a flag if pastes could be public
browseable somehow (maybe add a menu for that, loading circuits)

author:
by default empty string, but could be entered by a uploader, maybe per
by cookie.

title:
one may supply a title for the circuit, possibly with some delimiter
for a menu structure "example:analog:LC Filter". Must be unique, first
come, first served. When one already exists the title is dropped.

hash:
this becomes the actual shortened url, the schematic gets hashed, the
hash is encoded into something web-useable and then stored here.

schematic:
in the simplest case this might just sore the schematic text. maybe
gzipped. maybe one makes provisions to store urls here too, if
cloud/pastebin/github usage should be added in future.

On the server side then it needs:

• some interface which resolves titles and hashes and returns the
  associated schematics.
• some upload facility, gets user, title, policy, schematic. should do
  a basic check on the schematic syntax just enough against spam/abuse.
  Like a tinyurl or pastebin, after a successful upload the user gets
  the shortened links (by hash and maybe by title) back.
• some scrubbing script, possibl called daily or so by crontab. doing
  database maintenance, expiring old pastes etc.

The client needs:

• 'share' or whatever entry in the menu, which asks for author
  (preset from cookie), policy, title.
• maybe integrate the Circuit Examples into this infrastructure, they
  are loaded from web then. If so uploaded schematics could become
  browse and loadable from a menu in future (but needs some thinking
  because you dont want to present a zillion menu entries, possibly
  only highest accessed/voted7handpicked entries then)

Sorry I am a bit brainfarting here, I am not a web developer :D. I can't
really help much except for envision this feature

Christian

You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
#28 (comment)

from circuitjs1.

When I looked at this before I concluded that some kind of server-side feature was needed either to support local storage or to escape from the origin policy of the browser to access third-party services.

Using a database might be technically workable though I am not sure I like the statistical purging approach. Generally, looking after other people's data is not something I am keen to do for several reasons.

Christian, why don't you like the approach of using existing cloud services?

Iain

from circuitjs1.

BTW - I agree that a partial solution might be to have a compressed circuit format for URLs supported. GZIP might work but there is a lot of structure in the files that, if exploited, could probably achieve a much better result than a general compression algorithm.

from circuitjs1.

On 2016-11-03 12:32, Iain Sharp wrote:

When I looked at this before I concluded that some kind of
server-side feature was needed either to support local storage or to
escape from the origin policy of the browser to access third-party
services.

Using a database might be technically workable though I am not sure I
like the statistical purging approach. Generally, looking after other
people's data is not something I am keen to do for several reasons.

What are the reasons? I understand that such a thing comes with some
responsibility. But for something like this schematics I don't see too
much potential this could be abused, neither traffic nor content wise.
Of course you should be clear somehow in the terms of service that you
are not responsible for any uploads and may remove them for whatever
reason. While ideally it should be a no brainer and just work. Thats
why I propose this automatic scrubbing. Even if you set a default TTL
to some years, any unused (spamed) content will eventually be
purged. Publishing user content in the menu or make it
search/indexable needs to be taken with a grain of salt, I am aware of
that. But having shortended links only on demand/invite should be
mostly harmless.

btw: sqlite was just an easy idea. This is actually so simple that it
could be stored in the filesystem and served statically. One dir per
hash, schematic and metadata as file, title as symlink and scrubbing as
simple shell script using unix times.

Christian, why don't you like the approach of using existing cloud
services?

like you saied, b/c all that tracking BS almost all do, often one
is required to have an account there. And possibly you force anyone who
you share the things with into that too. Also you get multiple points of
failure, dependencies and any 'free' cloud service may decide to stop
its operation at any time for any reason.
This might be true for yours and Pauls website too. Who knows about the
future. But in spirit being an open source project I could at least
establish my own website then. I am not doing so yet because there is
no need, I like to use your online versions and I think you deserve the
fame for this project. Dunno how much traffic these sites cause and if
they cost you anything more or even generate some profit for you. For
me its just useful to have these services, thank you.

Either way, having some pastebin/tinyurl like way to share circuits
would be good. Exporting them as URL is way too long for example to
paste in IRC or in an email. So far i used tinyurl.com for that but its
a bit of a hazzle to copy paste things around and eventually such links
get lost unless i bookmark them for myself.

Christian

Iain

You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
#28 (comment)

from circuitjs1.

I have added integration with a URL shortener as part of the "Export as link" dialog. Live now on my version: http://lushprojects.com/circuitjs/

Dunno if I really want to add being a cloud storage provider, even in a very limited way, to my many activities. Supporting anything is always more work then you expect in my experience. I have added integration with Dropbox because their API is nice and high-level and compatible with a client-based solution.

When I get time (maybe later today) I plan to add support for Dropbox links in the query-string parameters and also add some file naming support to the circuits.

from circuitjs1.

?startCircuitLink paramter added to the query string. The load is done from the client without touching the server so the link server must be CORS compatible. Dropbox links are supported.

from circuitjs1.

On 2016-11-06 03:58, Iain Sharp wrote:

I have added integration with a URL shortener as part of the "Export
as link" dialog. Live now on my version:
http://lushprojects.com/circuitjs/

awesome! thank you very much!

Christian

Dunno if I really want to add being a cloud storage provider, even in
a very limited way, to my many activities. Supporting anything is
always more work then you expect in my experience. I have added
integration with Dropbox because their API is nice and high-level and
compatible with a client-based solution.

When I get time (maybe later today) I plan to add support for Dropbox
links in the query-string parameters and also add some file naming
support to the circuits.

i don't use dropbox, but might be useable for some folks :)

You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
#28 (comment)

from circuitjs1.

Closed as equivalent functionality now included.

from circuitjs1.