yeah, it's a bummer (she said, ignoring the appalling number of memories you quote below, that take us well out of bummer-ville), though I can think of a couple ways to code xfering memories you've made on an LJ instance of your own entries and import them at the same time as importing entries from that LJ, or if the importer tool does some history tracking you could have it be a separate tool. (You need to be able to link the old entry to the new, so either that gets done at the time of import by the entry importer, or, if the entry importer provides the right kind of historical information, in a separate and distinct import that refers back to the same linkage between old and new.) That only addresses importing memories of your own entries (which are easy to identify because they've got your username at the start of the URL), of course. Which was what I was thinking of at the time I bitched. However...
Importing your memories of other peoples entries is easy unless they are also moving their journals, because the URL that was memorized on your old journal is still good. If the URL being memorized is about to be bad, that opens up another kettle of fish.
One *could* look through each memory link, and then search via a couple different approaches, depending on how clever you need to be. And then it depends on how data is stored internally and whether we're talking about a standalone external tool or a DW application. Like, if you're trying to check "has X been imported as an entry into someone's DW account", you need an importer history, assuming the importer keeps some kind of history, to check the originating URL. Easy if you have database access. That's the easiest approach, and your tool wouldn't even need to keep tabs on things like "has the privacy setting changed on the imported entry" because you'll find out the hard way if you click on the link to it, which is normal (meaning, unsurprising to the average LJ user). I'm going to pretend I have access to DW's innards at this point, because the thought of spidering the whole system and then comparing content via a regex would make me cry, but could be done. You could even get clever based on some social engineering (most of us have the same username across multiple LJ instances, narrowing the scope of a search considerably). If that level of data (original URL | imported entry's URL) is not tracked by the entry importer, it should be, IMO. But I see a way or two around it, they're just very brute-force-y. (I'd be tempted as part of the final release rollout to force everyone to re-import their journals if this kind of data isn't being tracked already and the entry importer needs to be run again to capture it. This is what beta-testing is FOR.)
The problem's inherent to bookmarking in general, as you pointed out - you don't control the content's location so you can't stop linkrot if the content disappears.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
ninetydegrees
Re: Yeah,
on 2009-05-06 04:32 am (UTC)Importing your memories of other peoples entries is easy unless they are also moving their journals, because the URL that was memorized on your old journal is still good. If the URL being memorized is about to be bad, that opens up another kettle of fish.
One *could* look through each memory link, and then search via a couple different approaches, depending on how clever you need to be. And then it depends on how data is stored internally and whether we're talking about a standalone external tool or a DW application. Like, if you're trying to check "has X been imported as an entry into someone's DW account", you need an importer history, assuming the importer keeps some kind of history, to check the originating URL. Easy if you have database access. That's the easiest approach, and your tool wouldn't even need to keep tabs on things like "has the privacy setting changed on the imported entry" because you'll find out the hard way if you click on the link to it, which is normal (meaning, unsurprising to the average LJ user). I'm going to pretend I have access to DW's innards at this point, because the thought of spidering the whole system and then comparing content via a regex would make me cry, but could be done. You could even get clever based on some social engineering (most of us have the same username across multiple LJ instances, narrowing the scope of a search considerably). If that level of data (original URL | imported entry's URL) is not tracked by the entry importer, it should be, IMO. But I see a way or two around it, they're just very brute-force-y. (I'd be tempted as part of the final release rollout to force everyone to re-import their journals if this kind of data isn't being tracked already and the entry importer needs to be run again to capture it. This is what beta-testing is FOR.)
The problem's inherent to bookmarking in general, as you pointed out - you don't control the content's location so you can't stop linkrot if the content disappears.