| Newsgroups |
gmane.comp.web.services.rest |
| Message-ID |
<CAC9RQtj442toMw5P8GZUeR2L0frqp15Fh4=22BkEA_zn-usAUw@mail.gmail.com> |
--047d7bdcaa8c7a452a04f9c11a31
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
How does http 2.0 come into play with this with unsolicited pushes?
On Mon, May 19, 2014 at 4:49 PM, Philippe Marsteau
[email protected][rest-discuss]
<[email protected]> wrote:
>
>
> FWIW, HTTP is an APPLICATION (transfer) protocol and not a TRANPORT
> protocol. TCP is the transport protocol HTTP uses.
>
> I think the benefits of REST architectural style over Pub/Sub style is th=
e
> scalability associated to not require servers to keep tracks of clients.
> The statelessness constraint means a 2nd calls of a client
> shouldn't/mustn't assume something on the server following a previous cal=
l,
> like an HTTP (application) session could be used for on the server).
> Because of the assessment, you can literally swap one machine with anothe=
r
> (or use true load balancing solutions w/o sharing or distributing caches)
> without any impacts for the clients open "sessions" (from a client
> perspective). To achieve this, any input that a second call needs followi=
ng
> a first call should be transferred to client after each call (state is
> transfered to client instead of kept on server).
>
> This being said you certainly can model a pub/sub polling scenario within
> REST constraints. The pushing scenario however do require state on the
> server that belongs to client. Because the client determines lifecycle of
> these "push config" dynamic resources, eg when to delete it, that data ne=
ed
> to be kept in sync between machines, and handling* that extra state break=
s
> statelessness of REST (*handling like in auto-expiring subscriptions over
> time, etc.)
>
> The other technical pb of pub/sub over HTTP are firewalls or related
> network issues. It is not uncommon that clients have firewalls in place
> that let outgoing calls but require IP whitelisting to let calls come in.
> That further reduces scalability of such model (basically each client mus=
t
> be seen as a server and vice-versa). The clients costs is typically highe=
r
> than server (clients establish the HTTP connection and close them as
> appropriate for their use cases). This cost is acceptable because you
> usually have many clients for one server. If the server had to pay that
> connection cost (eg to push data), it would be central and all clients
> would deal with a less responsive server as a result.
>
> Finally, pub/sub model implies a level of trusts normal HTTP app servers
> do not need to have. Blindly connecting to any HTTP endpoint opens to
> security vulnerabilities. The client (subscriber) will typically expect
> some shared secret or key cert exchange, and the server may not be willin=
g
> to blindly post data to unknown locations.
>
> Hope this helps. Interesting discussion. Pub/sub scenarios clearly exist
> and are adapted for some use cases, but I don't thing HTTP transfer
> protocol is adapted. BTW, Roy's dissertation did mention Pub/Sub (as well
> as others) style before describing REST style; refer to it to compare the
> constraints with one another, and why he believed REST style was better
> suited for scalability.
>
> ---
> Phil
> On May 19, 2014 at 2:55:29 AM EDT, Hubert A Le Van Gong
> [email protected] [rest-discuss] <[email protected]> wrote:
>
>
>
> Hi Michael,
>
> I don't quite follow why you think a permanent HTTP session is against
> RESTful principles. Isn't the HTTP session management at a different leve=
l
> (transport) than the actual resource management and the stateless
> principles associated to it?
> In the same vein, would you also consider one cannot define a RESTful
> service over persistent HTTPS connections for instance?
>
>
> Best,
> Hubert
>
>
> On May 18, 2014, at 8:02 AM, Michael Schuerig [email protected][r=
est-discuss] <
> [email protected]> wrote:
>
> On Saturday 17 May 2014 18:15:13 Erik Wilde [email protected] [rest-
> discuss] wrote:
>
> > i guess i am having trouble with looking at a connection as a resource
> > with state (unless you talk about network monitoring and management
> > scenarios, which are an entirely different beast).
>
> No, a connection isn't a resource. But keeping a connection open from
> each client to the server puts a strain on the server. Ideally, a
> RESTful service is loaded only "dynamically" in the sense that the
> ("static") number of clients is irrelevant, what counts is the
> ("dynamic") number of requests per unit of time. My understanding of
> REST is that this is deliberate and very helpful for scalability. Open
> connections are a strain on a service even in the absence of any
> requests. For one thing, a single server can only manage a limited
> number of open connections at a time.
>
> In REST, at least as far as I understand it(!), state is only supposed
> to figure as transferred resource state; session state is prohibited.
>
> My understanding may be wrong and I'm perfectly willing to tone down the
> RESTful ideal for practical purposes. The point I'm trying to make is
> purely a matter of classification, ie that I think persistent
> connections are not RESTful.
>
> > but it is entirely possible to envisage that HTTP pull is like UPS
> > ground and free, whereas there may be UPS overnight which costs a bit
> > but is faster. if you do that, you get to specify your identifier, and
> > then (and this is why i call this "reverse REST") you become the
> > resource to be pushed to, i.e. your resource needs to be known by the
> > event source. there are tons of PubSub approaches out there, only
> > that coming up with one that works robustly and in a scalable at web
> > scale so far hasn't worked. the main reason is that for pull, sources
> > don't need to know the consumers, whereas for push that state needs
> > to be maintained, which is expensive.
>
> So, is "reverse REST" still RESTful? Yes, the individual push request
> from server to client probably qualifies. The architecture as a whole
> probably doesn't. As you write, state needs to be maintained which
> hinders scalability.
>
> A truly RESTful solution would have to do without such state. *I* don't
> see how that is possible, but that's why I started this discussion.
>
> Also, I'd like to repeat that I don't mean not being RESTful, or not
> being reactive, as some kind of condemnation. Both approaches offer very
> sensible advice in general, I'm interested in seeing how well they fit
> together.
>
> [...]
> > >> a push model. there are a variety of push protocols (PuSH, MQTT,
> > >> APN,
> > >> C2DM, sMAP) out there, but none so far has taken over the world.
> > >
> > > I don't know anything about these models/protocols. Do they work in
> > > practice at this time? In particular, if the client is a single-page
> > > application running in a browser?
> >
> > these are two very different questions. they work very well in
> > practice, for example across all iOS devices (APN), across all
> > android devices (C2DM), in building automation scenarios (sMAP), or
> > in large sensor network settings (MQTT).
>
> OK, I take these as existence proofs that push works in practice.
>
> > they all come with different
> > design goals and constraints, and it seems that you have something
> > specific in mind as well. as long as you don't better understand the
> > specific constraints of the scenario you have in mind, picking a
> > solution (or writing down the requirements for a new one) probably
> > will be hard.
>
> Right now I'm not trying to do anything, I'm first and foremost trying
> to understand the landscape. As a consequence, my specific questions
> keep changing. My starting point was the question "What would a
> 'reactive' and RESTful web application look like from browser through
> app server to database". Especially when it comes to the communication
> between browser (or rather JavaScript-client) and app server, I don't
> see how to reconcile statelessness and event-drivenness.
>
> Michael
>
> --
> Michael Schuerig
> mailto:[email protected] <[email protected]>
> http://www.schuerig.de/michael/
>
>
>=20=20=20
>
--=20
Studying for the Turing test
--047d7bdcaa8c7a452a04f9c11a31
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/htm=
l4/strict.dtd">
<html>
<head>
</head>
=20
<body style=3D"background-color: #fff;">
<span style=3D"display:none"> </span>
<!--~-|**|PrettyHtmlStartT|**|-~-->
<div id=3D"ygrp-mlmsg" style=3D"position:relative;">
<div id=3D"ygrp-msg" style=3D"z-index: 1;">
<!--~-|**|PrettyHtmlEndT|**|-~-->
<div id=3D"ygrp-text" >
=20=20=20=20=20=20
=20=20=20=20=20=20
<p><div dir=3D"ltr">How does http 2.0 come into play with this with u=
nsolicited pushes?</div><div class=3D"gmail_extra"><br><br><div class=3D"gm=
ail_quote">On Mon, May 19, 2014 at 4:49 PM, Philippe Marsteau <a href=3D"ma=
ilto:[email protected]">[email protected]</a> [rest-discuss] <span dir=3D=
"ltr"><<a href=3D"mailto:[email protected]" target=3D"_blank"=
>[email protected]</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"border-left:1px #ccc solid;">
<u></u>
=20
<div style=3D"background-color:#fff;">
<span>=C2=A0</span>
<div>
<div>
<div>
=20=20=20=20=20=20
=20=20=20=20=20=20
<p>FWIW, HTTP is an APPLICATION (transfer) protocol and not a TRANPOR=
T protocol. TCP is the transport protocol HTTP uses.</p><div><br></div><div=
>I think the benefits of REST architectural style over Pub/Sub style is the=
scalability associated to not require servers to keep tracks of clients. T=
he statelessness constraint means a 2nd calls of a client shouldn't/mus=
tn't assume something on the server following a previous call, like an =
HTTP (application) session could be used for on the server). Because of the=
assessment, you can literally swap one machine with another (or use true l=
oad balancing solutions w/o sharing or distributing caches) without any imp=
acts for the clients open "sessions" (from a client perspective).=
To achieve this, any input that a second call needs following a first call=
should be transferred to client after each call (state is transfered to cl=
ient instead of kept on server).</div>
<div><br></div><div>This being said you certainly can model a pub/sub polli=
ng scenario within REST constraints. The pushing scenario however do requir=
e state on the server that belongs to client. Because the client determines=
lifecycle of these "push config" dynamic resources, eg when to d=
elete it, that data need to be kept in sync between machines, and handling*=
that extra state breaks statelessness of REST (*handling like in auto-expi=
ring subscriptions over time, etc.)</div>
<div><br></div><div>The other technical pb of pub/sub over HTTP are firewal=
ls or related network issues. It is not uncommon that clients have firewall=
s in place that let outgoing calls but require IP whitelisting to let calls=
come in. That further reduces scalability of such model (basically each cl=
ient must be seen as a server and vice-versa). The clients costs is typical=
ly higher than server (clients establish the HTTP connection and close them=
as appropriate for their use cases). This cost is acceptable because you u=
sually have many clients for one server. If the server had to pay that conn=
ection cost (eg to push data), it would be central and all clients would de=
al with a less responsive server as a result.</div>
<div><br></div><div>Finally, pub/sub model implies a level of trusts normal=
HTTP app servers do not need to have. Blindly connecting to any HTTP endpo=
int opens to security vulnerabilities. The client (subscriber) will typical=
ly expect some shared secret or key cert exchange, and the server may not b=
e willing to blindly post data to unknown locations.</div>
<div><br></div><div>Hope this helps. Interesting discussion. Pub/sub scenar=
ios clearly exist and are adapted for some use cases, but I don't thing=
HTTP transfer protocol is adapted. BTW, Roy's dissertation did mention=
Pub/Sub (as well as others) style before describing REST style; refer to i=
t to compare the constraints with one another, and why he believed REST sty=
le was better suited for scalability.</div>
<div><br><div></div><div></div></div><span></span>---<br>Phil<div><div clas=
s=3D"h5"><span></span><div><div>On May 19, 2014 at 2:55:29 AM EDT, Hubert A=
Le Van Gong <a href=3D"mailto:[email protected]" target=3D"_blank">huber=
[email protected]</a> [rest-discuss] <<a href=3D"mailto:rest-discuss@yahoog=
roups.com" target=3D"_blank">[email protected]</a>> wrote:<br=
>
<blockquote type=3D"cite"><div>
=20=20
<span>=C2=A0</span>
<div>
=20=20=20=20=20=20=20
=20=20=20=20=20=20=20
<p>Hi Michael,</p><div><br></div><div>I don't quite follow why yo=
u think a permanent HTTP session is against RESTful principles. Isn't t=
he HTTP session management at a different level (transport) than the actual=
resource management and the stateless principles associated to it?</div>
<div>In the same vein, would you also consider one cannot define a RESTful =
service over persistent HTTPS connections for instance?</div><div><br></div=
><div><br></div><div>Best,</div><div>Hubert</div><div><br></div><div><br>
<div><div>On May 18, 2014, at 8:02 AM, Michael Schuerig <a href=3D"mailto:m=
[email protected]" target=3D"_blank">[email protected]</a> [=
rest-discuss] <<a href=3D"mailto:[email protected]" target=3D=
"_blank">[email protected]</a>> wrote:</div>
<br><blockquote type=3D"cite"><div style=3D"font-family:Helvetica;font-size=
:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spaci=
ng:normal;text-align:start;text-indent:0px;text-transform:none;white-space:=
normal;">
<div style=3D"font-size:13px;font-family:Arial,helvetica,clean,sans-serif;"=
><div><div style=3D"font-family:Georgia;"><p style=3D"margin:0px 0px 1em;">=
On Saturday 17 May 2014 18:15:13 Erik Wilde<span>=C2=A0</span><a href=3D"ma=
ilto:[email protected]" style=3D"font-family:Verdana;" target=3D"_blank">dr=
[email protected]</a><span>=C2=A0</span>[rest-<br>
discuss] wrote:<br><br>> i guess i am having trouble with looking at a c=
onnection as a resource<br>> with state (unless you talk about network m=
onitoring and management<br>> scenarios, which are an entirely different=
beast).<br>
<br>No, a connection isn't a resource. But keeping a connection open fr=
om<span>=C2=A0</span><br>each client to the server puts a strain on the ser=
ver. Ideally, a<span>=C2=A0</span><br>RESTful service is loaded only "=
dynamically" in the sense that the<span>=C2=A0</span><br>
("static") number of clients is irrelevant, what counts is the<sp=
an>=C2=A0</span><br>("dynamic") number of requests per unit of ti=
me. My understanding of<span>=C2=A0</span><br>REST is that this is delibera=
te and very helpful for scalability. Open<span>=C2=A0</span><br>
connections are a strain on a service even in the absence of any<span>=C2=
=A0</span><br>requests. For one thing, a single server can only manage a li=
mited<span>=C2=A0</span><br>number of open connections at a time.<br><br>In=
REST, at least as far as I understand it(!), state is only supposed<span>=
=C2=A0</span><br>
to figure as transferred resource state; session state is prohibited.<br><b=
r>My understanding may be wrong and I'm perfectly willing to tone down =
the<span>=C2=A0</span><br>RESTful ideal for practical purposes. The point I=
'm trying to make is<span>=C2=A0</span><br>
purely a matter of classification, ie that I think persistent<span>=C2=A0</=
span><br>connections are not RESTful.<br><br>> but it is entirely possib=
le to envisage that HTTP pull is like UPS<br>> ground and free, whereas =
there may be UPS overnight which costs a bit<br>
> but is faster. if you do that, you get to specify your identifier, and=
<br>> then (and this is why i call this "reverse REST") you be=
come the<br>> resource to be pushed to, i.e. your resource needs to be k=
nown by the<br>
> event source. there are tons of PubSub approaches out there, only<br>&=
gt; that coming up with one that works robustly and in a scalable at web<br=
>> scale so far hasn't worked. the main reason is that for pull, sou=
rces<br>
> don't need to know the consumers, whereas for push that state need=
s<br>> to be maintained, which is expensive.<br><br>So, is "reverse=
REST" still RESTful? Yes, the individual push request<span>=C2=A0</sp=
an><br>
from server to client probably qualifies. The architecture as a whole<span>=
=C2=A0</span><br>probably doesn't. As you write, state needs to be main=
tained which<span>=C2=A0</span><br>hinders scalability.<br><br>A truly REST=
ful solution would have to do without such state. *I* don't<span>=C2=A0=
</span><br>
see how that is possible, but that's why I started this discussion.<br>=
<br>Also, I'd like to repeat that I don't mean not being RESTful, o=
r not<span>=C2=A0</span><br>being reactive, as some kind of condemnation. B=
oth approaches offer very<span>=C2=A0</span><br>
sensible advice in general, I'm interested in seeing how well they fit<=
span>=C2=A0</span><br>together.<br><br>[...]<br>> >> a push model.=
there are a variety of push protocols (PuSH, MQTT,<br>> >> APN,<b=
r>
> >> C2DM, sMAP) out there, but none so far has taken over the wor=
ld.<br>> ><span>=C2=A0</span><br>> > I don't know anything =
about these models/protocols. Do they work in<br>> > practice at this=
time? In particular, if the client is a single-page<br>
> > application running in a browser?<br>><span>=C2=A0</span><br>&=
gt; these are two very different questions. they work very well in<br>> =
practice, for example across all iOS devices (APN), across all<br>> andr=
oid devices (C2DM), in building automation scenarios (sMAP), or<br>
> in large sensor network settings (MQTT).<span>=C2=A0</span><br><br>OK,=
I take these as existence proofs that push works in practice.<br><br>> =
they all come with different<br>> design goals and constraints, and it s=
eems that you have something<br>
> specific in mind as well. as long as you don't better understand t=
he<br>> specific constraints of the scenario you have in mind, picking a=
<br>> solution (or writing down the requirements for a new one) probably=
<br>
> will be hard.<br><br>Right now I'm not trying to do anything, I=
9;m first and foremost trying<span>=C2=A0</span><br>to understand the lands=
cape. As a consequence, my specific questions<span>=C2=A0</span><br>keep ch=
anging. My starting point was the question "What would a<span>=C2=A0</=
span><br>
'reactive' and RESTful web application look like from browser throu=
gh<span>=C2=A0</span><br>app server to database". Especially when it c=
omes to the communication<span>=C2=A0</span><br>between browser (or rather =
JavaScript-client) and app server, I don't<span>=C2=A0</span><br>
see how to reconcile statelessness and event-drivenness.<br><br>Michael<br>=
<br>--<span>=C2=A0</span><br>Michael Schuerig<br><a href=3D"mailto:michael@=
schuerig.de" style=3D"font-family:Verdana;" target=3D"_blank">mailto:michae=
[email protected]</a><br>
<a href=3D"http://www.schuerig.de/michael/" style=3D"font-family:Verdana;" =
target=3D"_blank">http://www.schuerig.de/michael/</a><br><br></p></div></di=
v></div></div></blockquote></div><br></div><p></p>
</div>
=20=20=20=20=20=20
=20=20=20=20
</div></blockquote></div></div></div></div><p></p>
</div>
=20=20=20=20=20
=20=20=20=20
<div style=3D"color:#fff;min-height:0;"></div>
</div>
=20=20
</div></div></blockquote></div><br><br clear=3D"all"><div><br></div>-- <br>=
<div dir=3D"ltr">Studying for the Turing test</div>
</div>
</p>
</div>
=20=20=20=20=20
<!--~-|**|PrettyHtmlStart|**|-~-->
<div style=3D"color: #fff; height: 0;">__._,_.___</div>
=20=20=20=20=20=20=20=20=20=20
=20=20
=20
=20=20=20=20
<div style=3D"clear:both"> </div>
<table cellspacing=3D4px style=3D"margin-top: 20px; margin-bottom: 10px=
; color: #2D50FD;">
<tbody>
<tr>
<td style=3D"font-size: 12px; font-family: arial; font-weight: bo=
ld; padding: 7px 5px 5px;" >
<a style=3D"text-decoration: none; color: #2D50FD=
" href=3D"https://groups.yahoo.com/neo/groups/rest-discuss/conversations/me=
ssages/19651;_ylc=3DX3oDMTJxaWt0dWkxBF9TAzk3MzU5NzE0BGdycElkAzQzMTkyNTUEZ3J=
wc3BJZAMxNzA1NzAxMDE0BG1zZ0lkAzE5NjUxBHNlYwNmdHIEc2xrA3JwbHkEc3RpbWUDMTQwMD=
UwNzY3NQ--?act=3Dreply&messageNum=3D19651">Reply via web post</a>
</td>
<td>•</td>
<td style=3D"font-size: 12px; font-family: arial; padding: 7px 5p=
x 5px;" >
<a href=3D"mailto:[email protected]?subject=3DRe%3A%20%5B=
rest-discuss%5D%20Reactive%20REST" style=3D"text-decoration: none; color: #=
2D50FD;">
Reply to sender </a>
</td>
<td>•</td>
<td style=3D"font-size: 12px; font-family: arial; padding: 7px 5p=
x 5px;">
<a href=3D"mailto:[email protected]?subject=3DRe%3A%=
20%5Brest-discuss%5D%20Reactive%20REST" style=3D"text-decoration: none; col=
or: #2D50FD">
Reply to group </a>
</td>
<td>•</td>
<td style=3D"font-size: 12px; font-family: arial; padding: 7px 5p=
x 5px;" >
<a href=3D"https://groups.yahoo.com/neo/groups/rest-discuss/con=
versations/newtopic;_ylc=3DX3oDMTJlaWowc2xmBF9TAzk3MzU5NzE0BGdycElkAzQzMTky=
NTUEZ3Jwc3BJZAMxNzA1NzAxMDE0BHNlYwNmdHIEc2xrA250cGMEc3RpbWUDMTQwMDUwNzY3NQ-=
-" style=3D"text-decoration: none; color: #2D50FD">Start a New Topic</a>
</td>
<td>•</td>
<td style=3D"font-size: 12px; font-family: arial; padding: 7px 5p=
x 5px;color: #2D50FD;" >
<a href=3D"https://groups.yahoo.com/neo/groups/=
rest-discuss/conversations/topics/19643;_ylc=3DX3oDMTM2b25lZzFzBF9TAzk3MzU5=
NzE0BGdycElkAzQzMTkyNTUEZ3Jwc3BJZAMxNzA1NzAxMDE0BG1zZ0lkAzE5NjUxBHNlYwNmdHI=
Ec2xrA3Z0cGMEc3RpbWUDMTQwMDUwNzY3NQR0cGNJZAMxOTY0Mw--" style=3D"text-decora=
tion: none; color: #2D50FD;">Messages in this topic</a>
(9)
</td>
</tr>
</tbody>
</table>
=20=20=20=20=20=20=20=20
<div id=3D"megaphoneModule">
<hr style=3D"height:2px ; border-width:0; color:#E3E3E3; backgr=
ound-color:#E3E3E3;">
<div>
<div class=3D"feature_intro">
<div style=3D"background-color:white;padding:0px 10px;">
<div class=3D"header" style=3D"margin-right:10px;display:in=
line-block;width:400px;">
<a rel=3D"nofollow" style=3D"text-decoration:none;" tar=
get=3D"_blank" href=3D"https://groups.yahoo.com/neo;_ylc=3DX3oDMTExc2JuanI3=
BF9TAzk3MzU5NzE0BGNmMTADQ1AEc2VjA21lZ2FwaG9uZQ--"><div style=3D"font-size:1=
5px;line-height:20px;color:blue;">Just launched ! Link preview on Yahoo Gr=
oups</div></a>
<div class=3D"snippet" style=3D"margin-top:5px;">Visit =
your Group on the web, simply paste the link to the article, photo or video=
you wish to share in the message you are composing.</div>
</div>
<div style=3D"display:inline-block;vertical-align:top;margi=
n-top:10px;">
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20
<a rel=3D"nofollow" target=3D"_blank" href=3D"http://ya=
hoogroups.tumblr.com/post/85014546066/bye-bye-blue-links-welcome-link-previ=
ew" name=3D"lm_btn_url" style=3D"text-decoration:none;">
<input type=3D"button" class=3D"lm-btn" value=3D"Le=
arn more" style=3D"font-size:14px;vertical-align:middle;height:30px;cursor:=
pointer;margin-bottom:10px;width:100px;background-color:rgb(250, 250, 250);=
margin-right:10px;" name=3D"lm_btn">
</a>
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20
<a rel=3D"nofollow" target=3D"_blank" href=3D"https://g=
roups.yahoo.com/neo;_ylc=3DX3oDMTExc2JuanI3BF9TAzk3MzU5NzE0BGNmMTADQ1AEc2Vj=
A21lZ2FwaG9uZQ--" name=3D"try_btn_url" style=3D"text-decoration:none;">
<input type=3D"button" class=3D"try-btn" value=3D"T=
ry it now" style=3D"font-size:14px;vertical-align:middle;height:30px;cursor=
:pointer;margin-bottom:10px;width:100px;background-color:rgb(250, 250, 250)=
;" name=3D"try_btn">
</a>
=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20
</div>
</div>
</div> </div>=20=20
=20=20=20=20=20
<hr style=3D"height:2px ; border-width:0; color:#E3E3E3; background-col=
or:#E3E3E3;">
</div>
<!------- Start Nav Bar ------>
=20
<!-- |**|begin egp html banner|**| -->
<div id=3D"ygrp-vital" style=3D"background-color: #f2f2f2; font-family: Ver=
dana; font-size: 10px; margin-bottom: 10px; padding: 10px;">
<span id=3D"vithd" style=3D"font-weight: bold; color: #333; text-transf=
orm: uppercase; "><a href=3D"https://groups.yahoo.com/neo/groups/rest-discu=
ss/info;_ylc=3DX3oDMTJlcmJyNXRwBF9TAzk3MzU5NzE0BGdycElkAzQzMTkyNTUEZ3Jwc3BJ=
ZAMxNzA1NzAxMDE0BHNlYwN2dGwEc2xrA3ZnaHAEc3RpbWUDMTQwMDUwNzY3NQ--" style=3D"=
text-decoration: none;">Visit Your Group</a></span>
<ul style=3D"list-style-type: none; margin: 0; padding: 0; display: in=
line;">
</ul>
</div>
<div id=3D"ft" style=3D"font-family: Arial; font-size: 11px; margin-top: 5p=
x; padding: 0 2px 0 0; clear: both;">
<a href=3D"https://groups.yahoo.com/neo;_ylc=3DX3oDMTJkaWY1ZGc1BF9TAzk3ND=
c2NTkwBGdycElkAzQzMTkyNTUEZ3Jwc3BJZAMxNzA1NzAxMDE0BHNlYwNmdHIEc2xrA2dmcARzd=
GltZQMxNDAwNTA3Njc2" style=3D"float: left;"><img src=3D"http://l.yimg.com/r=
u/static/images/yg/img/email/new_logo/logo-groups-137x15.png" height=3D"15"=
width=3D"137" alt=3D"Yahoo! Groups" style=3D"border: 0;"/></a>
<div style=3D"color: #747575; float: right;"> • <a href=3D"https://i=
nfo.yahoo.com/privacy/us/yahoo/groups/details.html" style=3D"text-decoratio=
n: none;">Privacy</a> • <a href=3D"mailto:rest-discuss-unsubscribe@yah=
oogroups.com?subject=3DUnsubscribe" style=3D"text-decoration: none;">Unsubs=
cribe</a> • <a href=3D"https://info.yahoo.com/legal/us/yahoo/utos/term=
s/" style=3D"text-decoration: none;">Terms of Use</a> </div>
</div>
<br>
<!-- |**|end egp html banner|**| -->
</div> <!-- ygrp-msg -->
=20
<!-- Sponsor -->
<!-- |**|begin egp html banner|**| -->
<div id=3D"ygrp-sponsor" style=3D"width:160px; float:right; clear:none; m=
argin:0 0 25px 0; background: #fff;">
<!-- Start Recommendations -->
<div id=3D"ygrp-reco">
</div>
<!-- End Recommendations -->
</div> <!-- |**|end egp html banner|**| -->
<div style=3D"clear:both; color: #FFF; font-size:1px;">.</div>
</div>
<img src=3D"http://geo.yahoo.com/serv?s=3D97359714/grpId=3D4319255/grpspI=
d=3D1705701014/msgId=3D19651/stime=3D1400507675" width=3D"1" height=3D"1"> =
<br>
<img src=3D"http://y.analytics.yahoo.com/fpc.pl?ywarid=3D515FB27823A7407E&a=
=3D10001310322279&js=3Dno&resp=3Dimg&cf10=3DCP" width=3D"1" height=3D"1">=20
<div style=3D"color: #fff; height: 0;">__,_._,___</div>
<!--~-|**|PrettyHtmlEnd|**|-~-->
</body>
<!--~-|**|PrettyHtmlStart|**|-~-->
<head>
<style type=3D"text/css">
<!--
#ygrp-mkp {
border: 1px solid #d8d8d8;
font-family: Arial;
margin: 10px 0;
padding: 0 10px;
}
#ygrp-mkp hr {
border: 1px solid #d8d8d8;
}
#ygrp-mkp #hd {
color: #628c2a;
font-size: 85%;
font-weight: 700;
line-height: 122%;
margin: 10px 0;
}
#ygrp-mkp #ads {
margin-bottom: 10px;
}
#ygrp-mkp .ad {
padding: 0 0;
}
#ygrp-mkp .ad p {
margin: 0;
}
#ygrp-mkp .ad a {
color: #0000ff;
text-decoration: none;
}
#ygrp-sponsor #ygrp-lc {
font-family: Arial;
}
#ygrp-sponsor #ygrp-lc #hd {
margin: 10px 0px;
font-weight: 700;
font-size: 78%;
line-height: 122%;
}
#ygrp-sponsor #ygrp-lc .ad {
margin-bottom: 10px;
padding: 0 0;
}
#actions {
font-family: Verdana;
font-size: 11px;
padding: 10px 0;
}
#activity {
background-color: #e0ecee;
float: left;
font-family: Verdana;
font-size: 10px;
padding: 10px;
}
#activity span {
font-weight: 700;
}
#activity span:first-child {
text-transform: uppercase;
}
#activity span a {
color: #5085b6;
text-decoration: none;
}
#activity span span {
color: #ff7900;
}
#activity span .underline {
text-decoration: underline;
}
.attach {
clear: both;
display: table;
font-family: Arial;
font-size: 12px;
padding: 10px 0;
width: 400px;
}
.attach div a {
text-decoration: none;
}
.attach img {
border: none;
padding-right: 5px;
}
.attach label {
display: block;
margin-bottom: 5px;
}
.attach label a {
text-decoration: none;
}
=20=20
blockquote {
margin: 0 0 0 4px;
}
.bold {
font-family: Arial;
font-size: 13px;
font-weight: 700;
}
.bold a {
text-decoration: none;
}
dd.last p a {
font-family: Verdana;
font-weight: 700;
}
dd.last p span {
margin-right: 10px;
font-family: Verdana;
font-weight: 700;
}
dd.last p span.yshortcuts {
margin-right: 0;
}
div.attach-table div div a {
text-decoration: none;
}
div.attach-table {
width: 400px;
}
div.file-title a, div.file-title a:active, div.file-title a:hover, div.fi=
le-title a:visited {
text-decoration: none;
}
div.photo-title a, div.photo-title a:active, div.photo-title a:hover, div=
.photo-title a:visited {
text-decoration: none;
}
div#ygrp-mlmsg #ygrp-msg p a span.yshortcuts {
font-family: Verdana;
font-size: 10px;
font-weight: normal;
}
.green {
color: #628c2a;
}
.MsoNormal {
margin: 0 0 0 0;
}
o {
font-size: 0;
}
#photos div {
float: left;
width: 72px;
}
#photos div div {
border: 1px solid #666666;
height: 62px;
overflow: hidden;
width: 62px;
}
#photos div label {
color: #666666;
font-size: 10px;
overflow: hidden;
text-align: center;
white-space: nowrap;
width: 64px;
}
#reco-category {
font-size: 77%;
}
#reco-desc {
font-size: 77%;
}
.replbq {
margin: 4px;
}
#ygrp-actbar div a:first-child {
/* border-right: 0px solid #000;*/
margin-right: 2px;
padding-right: 5px;
}
#ygrp-mlmsg {
font-size: 13px;
font-family: Arial, helvetica,clean, sans-serif;
*font-size: small;
*font: x-small;
}
#ygrp-mlmsg table {
font-size: inherit;
font: 100%;
}
#ygrp-mlmsg select, input, textarea {
font: 99% Arial, Helvetica, clean, sans-serif;
}
#ygrp-mlmsg pre, code {
font:115% monospace;
*font-size:100%;
}
#ygrp-mlmsg * {
line-height: 1.22em;
}
#ygrp-mlmsg #logo {
padding-bottom: 10px;
}
#ygrp-msg p a {
font-family: Verdana;
}
#ygrp-msg p#attach-count span {
color: #1E66AE;
font-weight: 700;
}
#ygrp-reco #reco-head {
color: #ff7900;
font-weight: 700;
}
#ygrp-reco {
margin-bottom: 20px;
padding: 0px;
}
#ygrp-sponsor #ov li a {
font-size: 130%;
text-decoration: none;
}
#ygrp-sponsor #ov li {
font-size: 77%;
list-style-type: square;
padding: 6px 0;
}=20
#ygrp-sponsor #ov ul {
margin: 0;
padding: 0 0 0 8px;
}
#ygrp-text {
font-family: Georgia;
}
#ygrp-text p {
margin: 0 0 1em 0;
}
#ygrp-text tt {
font-size: 120%;
}
#ygrp-vital ul li:last-child {
border-right: none !important;=20
}=20
-->
</style>
</head>
<!--~-|**|PrettyHtmlEnd|**|-~-->
</html>
<!-- end group email -->
--047d7bdcaa8c7a452a04f9c11a31--