No subject
Fri Aug 3 19:33:07 CDT 2007
eople start subscribing to it.<BR>
<BR>
I'm not sure how to handle the user requesting a new feed that doesn't exis=
t yet so that we can start pulling/publishing it.<BR>
<BR>> > I'm also not sure if I want to mix Atom nodes with RSS nodes =
etc. I<BR>> > could create 1 format to use for the "entry" and transf=
orm them to<BR>> > all match but for sites which add extra metadata t=
o entries such as<BR>> > Digg with its DiggCount I would like to main=
tain that. That is the<BR>> > beauty of XML :)<BR>> <BR>> But R=
SS isn't XML. :P<BR>> <BR>
<BR>
RSS isn't XML? I'm not sure what you mean lol. Are they not exposed as XML =
documents? lol.<BR>
<BR>> > That way Jabber clients who understand extensible items can d=
isplay<BR>> > them.<BR>> > <BR>> > I like the idea of the=
NodeID being the feeds url because then this<BR>> > "polling" servic=
e can use the feeds URL easily as the SET after<BR>> > downloading co=
ntent.<BR>> <BR>> Sure. :)<BR>> <BR>> > Any suggestions / re=
commendations would be great to hear!Another item<BR>> > I am unclear=
about is as I am polling for news data, how can I easily<BR>> > chec=
k if an "entry" exists already? I'd rather not have to keep a<BR>> > =
cache somewhere of all the items I have created already.<BR>> > <BR>&=
gt; > Although performance is going to suck if I have to check every ent=
ry<BR>> > before inserting. Is there a way to batch insert, and disal=
low<BR>> > duplicate entries based on *something* like entry title or=
something?<BR>> > <BR>> > <BR>> > It's nice to be back i=
n Jabber land :) I'm back into the old mindset<BR>> > where I have a =
ZILLION ideas rushing into my head about all the crazy<BR>> > things =
I can do with these XEPs lol.<BR>> > <BR>> > Any help would be =
great!<BR>> > <BR>> > Thanks so much!<BR>> <BR>> You migh=
t want to join this list for discussion:<BR>> <BR>> http://mail.jabbe=
r.org/mailman/listinfo/social<BR>> <BR>> "XMPP and Social Networking,=
Two Great Tastes That Taste Great Together!"<BR>> <BR>> /psa<BR>>=
<BR><BR>
Also a bunch of concerns pop into my head that I'm still unclear about when=
maintaining all this "feed" data.<BR>
<BR>
1. Is there any way I can just publish the latest feeds I pulled down and p=
ubsub discard any duplicates that may already exist? Or is the right way to=
handle this is to query every single entry individually to check if they e=
xist before publishing them?<BR>
<BR>
1.a If I have to query each individually. Would I make the entry id the url=
of the entry so that I can check for duplicates as I pull them down off th=
e web and read the entries? (example 4 old entries, but 1 new entry since l=
ast pull).<BR>
<BR>
2. Entry requesting. Is there any sort of querying we can use against them?=
If we are publishing tons of entries, 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 entry history of a couple months is=
going to be too efficient.<BR>
<BR>
Some of my concerns for #2 is because we are going to mobilize this, data p=
lans are expensive for mobile devices. In this country it can be $25/1.5MB/=
month.<BR>
<BR>
We want to try and make our mobile client query data efficiently but do the=
se capabilities exist in Pub/Sub?<BR>
<BR>
Thanks so much for the help :)<BR><br /><hr /> <a href=3D'' target=3D'_new'=
></a></body>
</html>=
--_9479f705-1487-41c3-a307-7c373594960c_--
More information about the Standards
mailing list