No subject

Fri Aug 3 19:33:07 CDT 2007

eceive events but how can I handle a user requesting a feed that is not ind=
exed on the server yet? So that the server can now start indexing that feed=
 and begin Publishing new entries it pulls (I will be writting the service =
which starts pulling feeds off the web). 
&nbsp; 
Also a bunch of concerns pop into my head that I'm still unclear about when=
 maintaining all this "feed" data. &nbsp; 1. Is there any way I can j=
ust publish the latest feeds I pulled down and pubsub discard any duplicate=
s that may already exist? Or is the right way to handle this is to query ev=
ery single entry individually to check if they exist before publishing them=
? &nbsp; 1.a If I have to query each individually. Would I make the e=
ntry id the url of the entry so that I can check for duplicates as I pull t=
hem down off the web and read the entries? (example 4 old entries, but 1 ne=
w entry since last pull). &nbsp; 2. Entry requesting. Is there any so=
rt of querying we can use against them? If we are publishing tons of entrie=
s, someone may want to browse/read them but only request X amount at a time=
, or only newer than a certain date etc. I don't think pulling the entire e=
ntry history of a couple&nbsp;months is going to be too efficient. &nbsp=
; Some of my concerns for #2 is because we are going to mobilize this, d=
ata plans are expensive for mobile devices. In this country it can be $25/1=
.5MB/month. &nbsp; We want to try and make our mobile client query da=
ta efficiently but do these capabilities exist in Pub/Sub? 
I'm sure I am just missing some concepts on how parts of PubSub work.&nbsp;=
 
 Thanks so much for&nbsp;your time&nbsp;:) <hr /> <a href=
=3D'' target=3D'_new'></a></body>
</html>=

--_1f5b6707-4f04-421b-a21d-e95dccb1af8d_--