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

Reply via email to