There seems to be a pattern here – MDG paying to host a nice party for everyone… and then leaving them stranded without any warning.
Of course I understand that @mike had to pull the plug once MDG stopped paying the bills… But they really could have done a better job helping to figure out a smooth transition, rather than simply letting it go dark.
Hey Mike, like said many times - it’s all your decision what happens to MeteorPad.
But I like to repeat myself: Why do you not provide a dump of the mongo db with the user owned and public content?
Can not understand why you lock that content.
Thanks for some feedback
Tom
Don’t be able to just repeat a short message and leave a database dump somewhere on the internet?
Looking forward to an answer
Tom
…and I don’t know what makes you think he should be allowed to do that. While it might be nice to get back those meteor examples, I don’t know that I or many others would want their privately made meteor sketches dumped for all to see. Not to mention the thousands of Example To-do apps you’d have to sift through since it created a new to-do every time anyone came to the site. AND 1.4 makes pretty much all of those sketches I saw/remember/worked on obsolete now.
What if we just let it go, huh?
This might have already been addressed in this thread, but it seems like this would be a great opportunity for MDG to provide another paid service. The C9 business model for dev workspaces is great and I think people would pay for this service on meteor pad. If you can’t get the code for it, I wonder how hard it would really be to re-implement?
From what I remember it was closed source and the author refused to open it when they closed it down.
Someone suggested a demo for a package I published, but doing a basic demo is not very useful for developers. Of course something as big as AutoForm has a great dev demo and tool. I was thinking of doing a quick “mini-meteorpad” for the demo. Would be interested in looking into how difficult it would be to build (client only?) re-implementation(?). I would be interested in looking into this, maybe with a couple of other people? Seems like this is such an important and missing tool for the community…
Found this “older” open source jsfiddle style javascript scratchpad called jsTinker. https://github.com/johncipponeri/jstinker/blob/master/js/jstinker.js
What about branching https://github.com/c9 and just tailoring it to meteor? Meteor runs great on c9 just not quite as quick and easy as meteorpad. Main issue will be hosting costs which is why would be awesome if Meteor did it as freemium service!
I have not used c9 so I’m not quite sure how it would work. Initially I thought, why not try to just run the Meteor client (with Blaze eg) with simulated server and without a real backend (client side collections). If there was an easy way to do it with c9 that would be great!
I haven’t really used docker but I think someone with docker know-how wouldn’t have a hard time at all! My main concerns would actually be that there might be an issue with mongodb licensing (which is why c9 took down it’s official meteor package), the hosting costs, and maybe the “auto-deployal” of c9 instances (not sure if they opened sourced that part).
I was actually thinking of something different. Rather than trying to run a full instance of the meteor app for a cilent side interaction, Meteor runs a simulation of the server in the client anyway. So really all one would need to do, is allow for dynamic and programatic definition of components and methods and you wouldn’t need to run a server for every client. So no Docker.
I guess meteorpad didn’t come back yet.
I’m thinking to start a new project.