>>3
I must have missed that one. Which should I work on, an alternative /prog/ or a prog synch that will allow other users of the client side script to continue to post in deleted threads.
If not, I'll make a command line interface to /prog/ and have it scrape /prog/ for new changes. Then posts that go into threads that no longer exist will go into a new thread with an id in the subject to match the deleted thread. Then if you still want a web interface, I'll make a webserver that runs on localhost that uses the interface to /prog/ as a backend.
Alternatively, it could be implemented in two components. One component would be the scraper and a server that listens only on localhost. Other applications can request threads from the localserver, or submit posts.
Then the /prog/ userscript will fetch content from the scraper server. When a post is made, the post goes to both the real /prog/ and the scraper server.
Name:
Anonymous2013-08-03 3:37
>>6
The scraper server can only accept posts made to threads that are deleted, otherwise it will end up out of sync with the real /prog/. Consider if someone intentionally posts on the scraper server without simultaneously posting to the real server.
Name:
Anonymous2013-08-03 3:41
>>7
That would be an error in the usage of the scrapper server, but you do have a point. The ordering of the posts could get mixed up. It's easier if the scraper gets all of its content from /prog/.
Name:
Anonymous2013-08-03 8:02
The swearing will continue until code quality improves.
>>10
The scrapper may evolve into a p2p /prog/. I think that has more potential than a centralized substitute.
Name:
Anonymous2013-08-03 19:03
>>10
Fuck off, librul scum. Anus has been our mascot since forever, and the problem with nikike's shitposting is that it's all over the fucking place instead of being contained in one or two threads.