Playground & Editors permalinks management

I don’t want to bother you and I remember I already posted about this a couple or a few times but I feel now would be the time to revive the topic.

We continue to accumulate permalinks that are used in searches (i.e. from the API>Examples) and overall we are exponentially increasing the number of ‘tests, non-working, intermediate steps’ links without any distinction between what is a test or a WIP and what is eventually either a published (in the forum) or deemed as ‘final’ version.

I can’t speak for the other users but I can tell you about how I make use of the tools that are offered to us. When creating a GUI with the editor or creating an NME mat, I make heavy use of the save to snippet to sketch and create. I sometimes end-up with 200 or more iterations where only a couple or a few of them are a real ‘step-up’, a ‘final’ or by any means worth to keep and show to others version.

But then, since they are anonymous and permanent, I cannot manage or delete them. I feel you should really think about implementing a strategy to at least tag and somewhat classify/manage all of these. And then, the sooner the better because the more we wait the more the situation will become unmanageable (of course, my opinion only).

So, I was thinking… what if:

  1. On the side of the user, we would add a select in the ‘save’ to choose from say ‘Test’, ‘Intermediate’, ‘Published’ or ‘Final/Distributed’. By default, the select would be on ‘Test’ and next the user would decide to change it to one of the other ‘states’
  2. On the side of the platform management, what if any link that has been posted in the forum or can somehow be recognized as a link that has been ‘distributed’ would be tagged as such.

Next, we could use this in searches and if necessary in the future - for any reason - we could sort the links that absolutely need to be kept from those who eventually could be put to a lower level access, archived or what do I know…

As a user, and I believe a responsible user, I really sometimes feel bad saving all these links without distinction knowing that they will simply accumulate. On the other hand, if I want to continue taking full advantage of this (AND I DO WANT), I have to save my work and be able to compare and make sure of my progress.

Thanks for taking the time to read and consider this (once again) and of course if there would be a will to work this part and if I can be of any help for it, don’t hesitate to ask.

Meanwhile, have a great day :sunglasses: :sunglasses:

1 Like

cc @PirateJC @carolhmj and @RaananW as it sounds like a great idea

I don’t think that’s an issue for us, storage-wise :smiley: But I do agree that having more options in snippet management would be good too!

Technically, someone could use the tags to differentiate if something is “test” or “ready”, but it would be nice to have more powerful capabilities. We could have the option for the PG search to return only “ready” stuff, for example.

1 Like

Yes. That was basically the idea. Improving search. Depending on what I search from say the ‘API examples from PG’ I can get over a thousand results, nearly all being irrelevant and most of’em not working.

Oh, this is planned. I wanted to do that a long time ago, but it’s not the highest priority we have, sadly.

My general idea was to do the following:

  1. Move the snippet DB to a different architecture, that will allow better control of search and storage
  2. Allow a user to work on a “local” implementation of the snippet server (in memory implementation of the DB server). This will allow you to run your own iterations (and as many as you wish), and then, eventually, save it to the public snippet server.
  3. When saving a playground not created by you (TBD - what is "by you " :slight_smile: ) save to a new snippet ID and don’t make new revisions. This will help making the public playground demos more static. And better searched.

We wanted to also allow marking “bad” or “non-working” playgrounds so users will know they won’t run. But this is a bit problematic - as the only way for us to know if something is working or not working is running it in a browser environment. It is hard to do it in the device where it is saved, because you might have changed the context to make your playground work (or exactly the other way - you did something to the global context that prevents the PG from working). Running every playground on server will be complex and, quite frankly, not my favorite path.

What we won’t do - we won’t allow people removing snippets. The snippet service was always immutable, and will stay this way.

I agree with you. We have noticed the same thing as well. improving search is coming “soon”. I really wanted to do that during the code freeze of 6.0, but sadly I couldn’t find the time. I hope to find the time in the near future to improve that.

Well, that’s because your approach is a lot more complex and evolved than my two-cents :grin:
I love it. It will take the time it needs but I’m happy to read above. Looks like this will be real cool and sustainable :hugs: :smiley:

1 Like

Nah. I would say the same. This is all too complex and too hard to master for only little or no benefit at all. I would try to keep it ‘simple’ as much as possible.

1 Like

Just remembered i wanted to comment on this :joy:

Maybe there could be a date tag attached to snippets on the back-end?
“last_date_accessed” or something like that,
when a snippet is loaded, check if last_date_accessed is older than 24 hours, if yes, update it to date now.
if a snippet haven’t been used for say, 3 years, it could be assumed that it can safely be culled from the snippet server? that would help a tiny bit that everything won’t get completely out of hand as the babylon community grows larger!

Personally i like to copy/paste and organize my “test” PGs in text files, but i’m a bit weird :wink:

1 Like

Actually, I do the same so either we are two weird person :crazy_face: or it isn’t just that weird :smiley:
Anyways, I still feel bad accumulating snippets on the server without distinction while perfectly knowing that 97% of them could be trashed (or at least should not be used in searches).

Me too!
A great weird community :joy:

1 Like