Timeline for Rather than remove site from /sites set status close, at least temporarily
Current License: CC BY-SA 2.5
18 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Sep 21, 2010 at 22:22 | comment | added | Sky Sanders | @downvoter ;-) - anonymous downvotes are not as anonymous as you think. ;-) | |
| Sep 20, 2010 at 16:33 | comment | added | Sky Sanders | @jon - the site's data engine runs on a schedule and performs various polls at regular intervals. So yes, it runs continuously but not constantly, if that makes sense. with the current rate limit I need to be pretty conservative in what and how often I pull but it appears that I can accomplish what I am trying to do with the current limits. | |
| Sep 20, 2010 at 16:11 | comment | added | Jonathan. | But stackusers.com isn't continually checking the API is it? | |
| Sep 20, 2010 at 0:02 | comment | added | Sky Sanders | @jon - what i meant is that when we talk about this in the context of, say, an end-user app that may or may not be running at any given time the value of a transient (temporary) signal such as flagging a site as deleted, is of little value and to code to such a signal would indeed result in brittle code. When you say 'user' that is what I thought. But... in the case of a web site that provides indexing services, stackusers.com for instance, which is continually running, a transient signal would be of great value in the interest of maintaining data integrity. | |
| Sep 19, 2010 at 23:18 | comment | added | Jonathan. | Right i didn't really understand what you just said, but effectively it's easier for sites to miss out a site than it is to get a state variable wrong? As it's easier to miss something out than to return the wrong value. I have not much idea of trnasient and salient mean or about the example you gave hut that's more for kevin I guess. | |
| Sep 19, 2010 at 14:10 | comment | added | Sky Sanders | @jonathon - the scenario you describe, i.e. an end user app supports kevins rather limited evaluation of the situation. A transient app should not rely on transient signals. A salient and concrete example supporting the feature is a persistent automated server process that fetches data - how is it to intelligently determine when to purge orphaned data? a signal, however transient, will be detected and action can be take proactively with confidence rather than reactively with no actual signal other than the absence of the record. but you get a tick from me for recognizing the issue. | |
| Sep 19, 2010 at 11:27 | comment | added | Jonathan. | Errm, I'd thought it was more important to let the user know that a site has been closed. The user thinks WhTF is gadgets? At least if there was site status=closed for a few weeks (or w/e) an app could have banner (etc) saying that gadgets has been closed. | |
| Sep 19, 2010 at 0:57 | comment | added | Kevin Montrose |
@Sky - This idea is fundamentally flawed because a client will always - always - have to handle the case where it never sees state=closed for a site that is taken down, this is a problem with signalling in general over a REST-ful API (unless the "messages" are persisted, which as I said we aren't going to do). All implementing this would do is encourage developers to write brittle, subtly broken code. Remember that [app]s in general do not control when they are run, that is very fundamental to the problem with this feature-request.
|
|
| Sep 18, 2010 at 23:52 | comment | added | Sky Sanders | @kevin - huh? the only thing that came though clear was the sarcasm. you seem to be determined to defend a position rather than discuss this. what that position is, other than 'no' is not entirely clear. | |
| Sep 18, 2010 at 23:36 | comment | added | Kevin Montrose | @Sky - ok, I'll get right on making API changes we know any client that doesn't have complete control over when and how its run won't be able to consume reliably. Top of the TODO. | |
| Sep 18, 2010 at 23:24 | comment | added | Sky Sanders | @kevin - the publisher of a signal is not aware of or concerned with subscribers. it's job is to publish a signal. it is the job of the subscribers, if any, to monitor and respond to a signal as is appropriate. If someone has some code that wants to proactively and authoritively deal with a site closure then they will monitor sites for that signal. If they don't monitor, they don't get the signal. I never even hinted at keeping dead sites around forever. Just leave the entry marked as deleted for a specific number of days, any specific number of days. | |
| Sep 18, 2010 at 23:00 | comment | added | Kevin Montrose |
If /sites malfunctioning is the concern, why not be concerned about it erroneously returning closed? The flaw is deleting data at the drop of a hat, which is purely a client concern. As soon as there's a "signal state," we have to worry about every client seeing it. What if some client misses the closed state, and now the site is gone (we're not keeping dead sites around forever, period); how should it behave?
|
|
| Sep 18, 2010 at 22:43 | history | edited | Sky Sanders | CC BY-SA 2.5 |
added 560 characters in body
|
| Sep 18, 2010 at 22:34 | history | edited | Kevin Montrose | CC BY-SA 2.5 |
edited title
|
| Sep 18, 2010 at 22:26 | answer | added | Kevin Montrose | timeline score: 2 | |
| Sep 18, 2010 at 22:23 | history | edited | Kevin Montrose |
edited tags
|
|
| Sep 18, 2010 at 21:22 | history | edited | Sky Sanders | CC BY-SA 2.5 |
added 158 characters in body; edited tags
|
| Sep 18, 2010 at 21:17 | history | asked | Sky Sanders | CC BY-SA 2.5 |