On the other hand, if I'm to follow my own thinking to its logical conclusion I should make the articles distributed too, with blobs and all.
On Wed, Apr 14, 2010 at 9:51 PM, Henrik Sarvell <hsarv...@gmail.com> wrote: > I don't know Alex, remember that we disconnected stuff, I'll paste the > remote E/R again (all of it, there is nothing else on the remotes): > > > (class +WordCount +Entity) > (rel article (+Ref +Number)) > (rel word (+Aux +Ref +Number) (article)) > (rel count (+Number)) > > The numbers here can then be used in the main app with (id) to actually > locate the objects in question. > > Could the *Ext functionality still be used somehow? I have a hard time > understanding how if I don't map the feed (parent) -> article (child) > relationship remotely, I mean at some point I will have to filter all > retrieved articles against a set of articles fetched locally (all articles > belonging to my Twitter feed), if I don't store the connections remotely. > Storing the feed -> article links remotely will let me avoid checking > locally, and it's that check that is the bottleneck at the moment. > > I suppose you could find some clever way of speeding up the local > filtering, at the moment I'm simply loading all Twitter articles with > collect and then throwing away all remotely retrieved articles that are not > in that list. However that just seems like a duct tape solution, even if it > works to begin with it won't work for long. > > /Henrik > > > > On Sun, Apr 11, 2010 at 4:13 PM, Alexander Burger <a...@software-lab.de>wrote: > >> On Sun, Apr 11, 2010 at 02:19:23PM +0200, Henrik Sarvell wrote: >> > Thanks Alex, I will go for the the reversed range and check out >> select/3. >> >> Let me mention that since picoLisp-3.0.1 we have a separate >> documentation of 'select/3', in "doc/select.html". >> -- >> UNSUBSCRIBE: mailto:picol...@software-lab.de?subject=unsubscribe >> > >
