1

I noticed today, due to some exceptions, that sites that do not perform in beta can be closed and thus removed from /sites.

If you persist data, you will need to check your data every time you pull /sites.

8-\

I would suggest adding a site.state, closed, and keep the site in the list for a short period of time to allow an intelligent response to the event.

response to kevin

This is assuming that sites behaves perfectly. If, for any reason, sites does something like returning an empty array, or a malformed site, automated processes will erroneously delete or disassociate data.

Where as if an explicit indication that the site is removed were present appropriate and proactive action could be taken.

This is another case where a little bit of compromise in providing fault tolerance upstream would be of great benefit downstream and easily justify a few extra bytes in the /sites response.

see http://area51.stackexchange.com/proposals/614/electronic-gadgets

Improve this question
12
  • 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?
    – Kevin Montrose
    Commented Sep 18, 2010 at 23:00
  • @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.
    – Sky Sanders
    Commented Sep 18, 2010 at 23:24
  • @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.
    – Kevin Montrose
    Commented Sep 18, 2010 at 23:36
  • @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.
    – Sky Sanders
    Commented Sep 18, 2010 at 23:52
  • 1
    @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.
    – Kevin Montrose
    Commented Sep 19, 2010 at 0:57
  • 2
    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.
    – Jonathan.
    Commented Sep 19, 2010 at 11:27
  • @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.
    – Sky Sanders
    Commented Sep 19, 2010 at 14:10
  • 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.
    – Jonathan.
    Commented Sep 19, 2010 at 23:18
  • @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.
    – Sky Sanders
    Commented Sep 20, 2010 at 0:02
  • But stackusers.com isn't continually checking the API is it?
    – Jonathan.
    Commented Sep 20, 2010 at 16:11
  • @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.
    – Sky Sanders
    Commented Sep 20, 2010 at 16:33
  • @downvoter ;-) - anonymous downvotes are not as anonymous as you think. ;-)
    – Sky Sanders
    Commented Sep 21, 2010 at 22:22

1 Answer 1

Reset to default
2

If you're persisting data, the omission of the site is enough of a signal that its been removed (for whatever reason).

Keep old sites around indefinitely is just polluting /sites, and removing them after some fixed time period means any consumers have to deal with their eventual removal anyway. Might as well just remove them and be done with it.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .