ehehe... really, this is where we need a Real Developer to do a reality-check on what might be possible. And even then, lots of stuff is possible but not necessarily feasible (or sometimes, just not very wise, if it's a security issue, or a space issue, or whatever).
Actually, it seems to me that the one way in which "storing in app" could be a problem is WHAT gets stored... the old ugly of being shut down b/c something is sitting on the servers that's illegal in that jurisdiction. Seems to me that the easiest way to get around the bs legal stuff -- and to let people truly bookmark whatever the hell they damn please -- is to just save the links. It's not illegal to link to someone else's stuff (or else google would be in trouble for indexing all that shota, etc). It's when you get into "saving a copy" that you open yourself to ways that the crazy-ass censorship weenies could use to smack you.
(I hadn't actually thought in terms of who gets to see the archived content! I think I had loosely thought of it as "what I save, I see" and it'd only be visible to others based on my personal privacy settings for that link and/or my account. I suppose app-wide access would come into play, if your account were public and the link were also public.)
And as much as I get the need to save fic that might be deleted later -- seeing how we discuss this while on my todo list is an upcoming deletion all of an author's entries from a fic archive, sadness -- I think it's also asking a bit much of an application that's designed to save links. I mean, a good application is one that does what it does, and does it well; where applications start going wrong IMO is when they try to do everything, including the kitchen sink. So me, personally, in designing this kind of thing, I tend to say: what's the main goal? what's the primary purpose? and focus on how the application can do that, and just that. Not saying it can't do more later (possibly) but first it should do that primary thing really, really well.
Or shorter: I do see a definite value in archiving content, but I'm not entirely convinced that it's wise to try and buckle that onto an app whose purpose is to find content. It seems like that would be best as a counterpart... or maybe that's just another way to say, "that's a phase II, when the primary goal is satisfied completely, and there's a chance to expand". Or rather than "expand", to "develop a concurrent app that stores" that works in tandem with "an app that finds".
But still, a Real Developer might have input on all this that could shed a new/better light on things, too, so I'm going to keep it in the list of requirements, and see what conversation it spurs when I repost the (compiled, organized) list.
no subject
Date: 3 Oct 2011 09:00 pm (UTC)Actually, it seems to me that the one way in which "storing in app" could be a problem is WHAT gets stored... the old ugly of being shut down b/c something is sitting on the servers that's illegal in that jurisdiction. Seems to me that the easiest way to get around the bs legal stuff -- and to let people truly bookmark whatever the hell they damn please -- is to just save the links. It's not illegal to link to someone else's stuff (or else google would be in trouble for indexing all that shota, etc). It's when you get into "saving a copy" that you open yourself to ways that the crazy-ass censorship weenies could use to smack you.
(I hadn't actually thought in terms of who gets to see the archived content! I think I had loosely thought of it as "what I save, I see" and it'd only be visible to others based on my personal privacy settings for that link and/or my account. I suppose app-wide access would come into play, if your account were public and the link were also public.)
And as much as I get the need to save fic that might be deleted later -- seeing how we discuss this while on my todo list is an upcoming deletion all of an author's entries from a fic archive, sadness -- I think it's also asking a bit much of an application that's designed to save links. I mean, a good application is one that does what it does, and does it well; where applications start going wrong IMO is when they try to do everything, including the kitchen sink. So me, personally, in designing this kind of thing, I tend to say: what's the main goal? what's the primary purpose? and focus on how the application can do that, and just that. Not saying it can't do more later (possibly) but first it should do that primary thing really, really well.
Or shorter: I do see a definite value in archiving content, but I'm not entirely convinced that it's wise to try and buckle that onto an app whose purpose is to find content. It seems like that would be best as a counterpart... or maybe that's just another way to say, "that's a phase II, when the primary goal is satisfied completely, and there's a chance to expand". Or rather than "expand", to "develop a concurrent app that stores" that works in tandem with "an app that finds".
But still, a Real Developer might have input on all this that could shed a new/better light on things, too, so I'm going to keep it in the list of requirements, and see what conversation it spurs when I repost the (compiled, organized) list.