Addendum to RSS spec --OOPS!

[Fairlight]

Ugh.  It figures.  I didn't go far enough in one area.  To guarantee you
have not processed a record request already, you MUST specify a
serialisation of some sort.  I figured host, date, and time would be
enough.  No way.  You could have 20 requests for 20 different tables come
through in the same second--especially if it was generated by processing
that affects a lot of data in different places.  They'd all have the same
host, date, and time.

What they -need- is a serialisation string of some sort.  It should be a
unique identifier.  Ideally, when programming in other languages, I use the
date+time plus the PID.  But a PID isn't directly available in fP.

Well, this can be worked around any number of ways...even if you use USER
to go fetch a PID from a child.  That would be unique to that time and
date.  There are other methods, I'm just not used to doing them in fP.  I
suppose a carefully seeded random could work, if it would be a bit risky.
Feel free to suggest alternatives.  I'm half braindead right now.

At any rate, you'd only need to modify the spec to following:

<!ELEMENT record (record_publish_date,record_publish_time,serial,field*)>
<!ELEMENT serial (#PCDATA)>

You then have, in every <record> element, a <serial>unique_id</serial> tag
for that request.  You check the date, time, host, -and- the serialisation
string.

A very critical component, and I had to leave it out the first time.  Doh!

At any rate, the extent of change isn't large.  One extra field per record
request, and a change to the DTD.  No biggie.

The devil is in the details though.  I anxiously await news of whether the
lookup arguments can be variable.  If they can, I very well may take a
crack at this and do a completely finished module with docs and examples.
If not, it'd have to be docs and examples.  :)  Well, I could supply the
generic parsing code.  But the storage logic wouldn't be as modular as I'd
like.  We'll see what the answers are.

Heck, we'll see if anyone thinks it's worth doing in the first place.  :)
For a fairly old technology (4 years), I just stumbled upon it now and it
seemed like a very good solution to a long-time bugaboo regarding
multi-machine data synchronisation.  I've never been happy with any of the
solutions I've seen implemented.  The big drawback is the usual downtime
associated with synchronisng either whole files, or data sets.  And most
places only add records--this would let you perform all three post-type
operations at a high degree of granularity with no downtime.

Actually...ACTUALLY...you have to write at least one pseudo-RSS file
anyway.  More likely two of them if you want "master daily" redundancy,
although that could be generated on-demand, as could anything even longer,
really, since you're feeding it date and time criterion to generate it.
But nothing says you -only- would have to write the file only in the format
I came up with.  In theory, if you were data-wholesaling for someone, you
could lock down access to the feed, and you could write out an official RSS
feed as well--one that could be used by any old aggregator.  Let them parse
the encoded sub-xml.  It's as doable as weblogs with encoded HTML, and they
do that all the time.  This could be a nice distribution scheme, depending
what you need to do.  You could just charge for access to the feed, lock it
down with .htaccess restrictions, and voila.  It definitely has multiple
applications for fP.

Then again, that's my PoV.  I could be excited over nothing.  It -is-
relatively old technology.  I'm surprised I haven't heard of anyone
combining the two, to date.  It seems near ideal, barring actual native
client/server realtime connectivity.

Anyway, I've thought far too hard on spec for one night.  Comments are
definitely welcome.  Interested to see if there's as much potential as I
think there is.  I do need some sack time though.  Zap.  *snore*

mark->
-- 
Fairlight->   ||| "While there's life, there's six   | Fairlight Consulting
  __/\__      ||| of one and a half-dozen of the     |
 <__<>__>     ||| other..." --The Doctor             | http://www.fairlite.com
    \/        |||                                    | info at fairlite.com