Re: [Bodington-developers] xml foods

[Selwyn L. <sel...@ph...>]

yes these are good cases for RSS, sorry If I wasn't clearer that the=20
business cases are for known > less random consumers...


we may base this on IP in our initial prototypes

in the proposed GCWS agent model for example only known agents may=20
connect to the web service and only known GCWS servers to the GCWS agent

there are cases where both agent and server are consumers on demand,=20
there are cases for caching [now looking at caldav as a possible cache]

I'll bring this up on the GCWS blog later


apologies Peter :)


Peter Crowther wrote:

>>From: Selwyn Lloyd
>>Is there a protocol or spec for feeds which once read are eaten so to=20
>>speak... i.e. you eat them once only go back and their gone...
>>   =20
>>
>
>If you consider the Web constraints of:
>
>- Consumers are anonymous, may be connected erratically and may change t=
heir address or may only be able to connect through a proxy (consider dia=
l-up AOL subscribers or road warriors);
>
>- Servers may be clustered, and anything that decreases cluster performa=
nce is a Bad Thing;
>
>- Many users have webmail with no or limited access except via HTTP;
>
>- Bandwidth is cheap
>
>then the reason for the current architecture becomes clear.
>
>You can't push to the consumer because you don't know what address they'=
re on, or even whether they're online.  You don't want to maintain a queu=
e on the server (unless it's at the consumer's expense) because it requir=
es synchronisation within a cluster plus state storage - expensive.  You =
can't use the only (fairly) reliable store-and-forward protocol whose que=
ue cost is borne by the consumer because there's a good chance any custom=
 client can't read the queue (and the standard clients like Hotmail will =
suck the supposedly-custom messages out anyway).  Oh, and you'd need cust=
om software at the server to push the content.
>
>By contrast, publishing a file to all the front-end Web servers in a clu=
ster gives no synchronisation problems at the server, requires no storage=
 at the server, requires no custom software at the server (you can author=
 a RSS feed in ed if you're feeling masochistic), and any consumer can ac=
cess it from any location at any time via HTTP, which is proving to be al=
most the only universally-available access mechanism.  Yes, polling is re=
quired, but bandwidth is cheap and good interop outweighs bandwidth (almo=
st) every time - otherwise verbose protocols like HTML and XML wouldn't b=
e standard.
>
>Just my =A30.02...
>
>		- Peter
>
>
> =20
>

--=20
Selwyn Lloyd
Phosphorix=20
Open Source Systems for Lifelong Learning
skype: selwyn_lloyd
tel: 07979240124
irc://irc.ionode.org
support channel: #ionode
support email: de...@ph...
web: http://www.phosphorix.co.uk=20
forum: http://forum.ionetwork.ac.uk