| Newsgroups |
gmane.comp.web.services.rest |
| Message-ID |
<CAAgVzdhgAt-AO0G7Lwj8am=CMrDknoBKCDXjEa0_vBn1jKx=3Q@mail.gmail.com> |
--047d7bdc1bd03327e604fa123236
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Hi Michael,
I signed the reactive manifesto a while ago. I do think the RESTful
applications need to be "reactive". To achieve that, I think a RESTful API
should not only provide the data, but also afford how to manipulate the
data when remote retrieval is expensive and not reliable. Query via path
might be the most straightforward and safest way to that. Thinking about
the model of html, we can hardly develop any modern web applications
without the DOM. Furthermore, maybe sounding crazy, I also think a RESTful
API without code-on-demand is a *dumb* API.
I like what Jafar Husain showed about netflix's approach of jsong and
effective pational caching control. Thanks for the link.
Cheers,
Dong
On Sat, May 17, 2014 at 4:07 PM, Erik Wilde [email protected][rest-discuss]
<[email protected]> wrote:
>
>
> hello michael.
>
> On 2014-05-17, 10:33, Michael Schuerig [email protected]
> [rest-discuss] wrote:
> > The "reactive" buzzword has been conspicuously absent from this list.
> > I'll try to fill this much needed gap.
>
> haven't really seen it buzzing that much, but if you had to give it at
> least a little substance, how would you explain what it means? just
> something that's driven by events rather than clients?
>
>
> > I've recently watched a presentation by Jafar Husain
> > http://www.infoq.com/presentations/netflix-reactive-rest
> > where he describes something he calls "Reactive REST". I agree on the
> > "reactive", however I have doubts about the "REST". In this particular
> > case, all communication between a client and a server is over persisten=
t
> > connection to a single endpoint. If there's anything resembling
> > resources, they are not identified by URIs. The persistent connection
> > IMHO is a case of "conversational" state that REST is rather opposed to=
.
> > No HATEOAS in sight.
>
> sounds like websockets (maybe not technically, but as the general idea).
> to me, REST is on a different level than this plumbing. in the same way
> as you can do REST and notREST over HTTP, the same probably applies to
> any of the alternative interaction styles. as you point out, REST has
> more (and more abstract) constraints than just the protocol that's used.
>
>
> > What I'm pondering is whether an API can be RESTful and reactive at the
> > same time or if is impossible as a matter of principle. AFAICT, a
> > reactive API requires some way for the server to send events to the
> > client. I don't think polling qualifies, which leaves a persistent
> > connection. In effect, the server has to keep some amount of state for
> > each session.
>
> not sure i agree that polling or long polling are the only (or best)
> alternatives. there's quite of stuff to be done in the area that i often
> refer to as "reverse REST": clients subscribe, and then there's 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.
>
> it'll be interesting to see how this plays out in june at the w3c's web
> of things workshop. clearly, in sensor scenarios, it would be very
> convenient to have these kind of alerts, have them in a loosely coupled
> and scalable way, and have them via protocols that are universally
> supported. it may be the case that w3c will start working on something
> in that space, but we'll know more after that workshop.
>
> http://www.w3.org/2014/02/wot/
>
> http://dret.net/netdret/publications#wil14a is a position paper that we
> have submitted to this workshop. it may be the case that activity
> streams take over as the new atom. we'll see about that, but they are
> not all that different, and they use JSON, so all is good.
>
> and in the same way as you can layer PuSH on atom to have a push model
> on top of atom's data model, you can do the same for activity streams.
> that might be the way open push protocols are going: you can poll for
> activities, or you can subscribe to an activity hub that pushes to you
> whatever you has subscribed to.
>
> in my eyes, this could still be RESTful, only that of course you would
> end up having more resources (such as subscriptions that need to be
> managed and so on).
>
> anyway, a very good question, a very interesting field, and with the
> whole IoT/WoT movement now getting a serious hype push, maybe we'll get
> to something open, useful, and RESTful in the next couple of years.
>
>
> > Keeping session state has traditionally been regarded as a hindrance to
> > scalability. Has technology advanced so much, eg with asynchronous,
> > event-driven ("reactive") servers, that this is no longer a problem?
>
> just a question of cost. different protocols have different solutions
> (PuSH subscriptions time out automatically, sMAP subscriptions never
> time out), based on different scenarios. anything push-based is more
> expensive than pure pull, because services/hubs need to keep track of
> subscribers. but if the cost is smaller that the benefit, then this will
> happen one way or another.
>
>
> > Frankly, I'm lacking experience with systems where this kind of
> > scalability would be required, so I'd happily use persistent
> > connections, at least to begin with. Nonetheless, I'm interested in you=
r
> > insights.
>
> web of things scenarios simply cannot work with long polling. if you
> want to be connected to thousands of sensors in your building to figure
> out when one is telling you that there is a fire, then you cannot have
> open connections to all of them. the answer here is a layered
> architecture, maybe some of it hidden as implementation details (sensors
> just speaking MQTT to a hub), and other things exposed on the web level
> (you being able to subscribe to that hub and get alerts). many solutions
> have been built around this general pattern, but so far we lack a single
> and coherent answer where to draw the boundary between the
> implementation details and the open part, and what we should use for
> that open part. as mentioned above, maybe that workshop will bring
> together enough interested parties to start working on that issue.
>
> cheers,
>
> dret.
>
> --
> erik wilde | mailto:[email protected] - tel:+1-510-2061079 |
> | UC Berkeley - School of Information (ISchool) |
> | http://dret.net/netdret http://twitter.com/dret |
>
>=20=20
>
--047d7bdc1bd03327e604fa123236
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">Hi Michael,=C2=A0<div><br></div><div>I signed the=
reactive manifesto=C2=A0a while ago. I do think the RESTful applications n=
eed to be "reactive". To achieve that, I think a RESTful API shou=
ld not only provide the data, but also afford how to manipulate the data wh=
en remote retrieval is expensive and not reliable. Query via path might be =
the most straightforward and safest way to that. Thinking about the model o=
f html, we can hardly develop any modern web applications without the DOM. =
Furthermore, maybe sounding crazy, I also think a RESTful API without code-=
on-demand is a *dumb* API.=C2=A0</div>
<div><br></div><div><span style=3D"font-family:arial,sans-serif;font-size:1=
2.800000190734863px;">I like what Jafar Husain showed about netflix's a=
pproach of jsong and effective pational caching control. Thanks for the lin=
k.=C2=A0</span></div>
<div><font face=3D"arial, sans-serif"><br></font></div><div><font face=3D"a=
rial, sans-serif">Cheers,</font></div><div><font face=3D"arial, sans-serif"=
><br></font></div><div><font face=3D"arial, sans-serif">Dong<br></font><div=
class=3D"gmail_extra">
<br><br><div class=3D"gmail_quote">On Sat, May 17, 2014 at 4:07 PM, Erik Wi=
lde <a href=3D"mailto:[email protected]">[email protected]</a> [rest-discus=
s] <span dir=3D"ltr"><<a href=3D"mailto:[email protected]" ta=
rget=3D"_blank">[email protected]</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;"=
>
<u></u>
=20
<div style=3D"background-color:rgb(255,255,255);">
<span>=C2=A0</span>
<div>
<div>
<div>
=20=20=20=20=20=20
=20=20=20=20=20=20
<p>hello michael.<br>
<br>
On 2014-05-17, 10:33, Michael Schuerig <a href=3D"mailto:michael.lists@schu=
erig.de" target=3D"_blank">[email protected]</a> <br></p><div class=
>
[rest-discuss] wrote:<br>
> The "reactive" buzzword has been conspicuously absent from t=
his list.<br>
> I'll try to fill this much needed gap.<br>
<br></div>
haven't really seen it buzzing that much, but if you had to give it at =
<br>
least a little substance, how would you explain what it means? just <br>
something that's driven by events rather than clients?<div class><br>
<br>
> I've recently watched a presentation by Jafar Husain<br>
> <a href=3D"http://www.infoq.com/presentations/netflix-reactive-rest=
" target=3D"_blank">http://www.infoq.com/presentations/netflix-reactive-res=
t</a><br>
> where he describes something he calls "Reactive REST". I agr=
ee on the<br>
> "reactive", however I have doubts about the "REST"=
. In this particular<br>
> case, all communication between a client and a server is over persiste=
nt<br>
> connection to a single endpoint. If there's anything resembling<br=
>
> resources, they are not identified by URIs. The persistent connection<=
br>
> IMHO is a case of "conversational" state that REST is rather=
opposed to.<br>
> No HATEOAS in sight.<br>
<br></div>
sounds like websockets (maybe not technically, but as the general idea). <b=
r>
to me, REST is on a different level than this plumbing. in the same way <br=
>
as you can do REST and notREST over HTTP, the same probably applies to <br>
any of the alternative interaction styles. as you point out, REST has <br>
more (and more abstract) constraints than just the protocol that's used=
.<div class><br>
<br>
> What I'm pondering is whether an API can be RESTful and reactive a=
t the<br>
> same time or if is impossible as a matter of principle. AFAICT, a<br>
> reactive API requires some way for the server to send events to the<br=
>
> client. I don't think polling qualifies, which leaves a persistent=
<br>
> connection. In effect, the server has to keep some amount of state for=
<br>
> each session.<br>
<br></div>
not sure i agree that polling or long polling are the only (or best) <br>
alternatives. there's quite of stuff to be done in the area that i ofte=
n <br>
refer to as "reverse REST": clients subscribe, and then there'=
;s a push <br>
model. there are a variety of push protocols (PuSH, MQTT, APN, C2DM, <br>
sMAP) out there, but none so far has taken over the world.<br>
<br>
it'll be interesting to see how this plays out in june at the w3c's=
web <br>
of things workshop. clearly, in sensor scenarios, it would be very <br>
convenient to have these kind of alerts, have them in a loosely coupled <br=
>
and scalable way, and have them via protocols that are universally <br>
supported. it may be the case that w3c will start working on something <br>
in that space, but we'll know more after that workshop.<br>
<br>
<a href=3D"http://www.w3.org/2014/02/wot/" target=3D"_blank">http://www.w3.=
org/2014/02/wot/</a><br>
<br>
<a href=3D"http://dret.net/netdret/publications#wil14a" target=3D"_blank">h=
ttp://dret.net/netdret/publications#wil14a</a> is a position paper that we =
<br>
have submitted to this workshop. it may be the case that activity <br>
streams take over as the new atom. we'll see about that, but they are <=
br>
not all that different, and they use JSON, so all is good.<br>
<br>
and in the same way as you can layer PuSH on atom to have a push model <br>
on top of atom's data model, you can do the same for activity streams. =
<br>
that might be the way open push protocols are going: you can poll for <br>
activities, or you can subscribe to an activity hub that pushes to you <br>
whatever you has subscribed to.<br>
<br>
in my eyes, this could still be RESTful, only that of course you would <br>
end up having more resources (such as subscriptions that need to be <br>
managed and so on).<br>
<br>
anyway, a very good question, a very interesting field, and with the <br>
whole IoT/WoT movement now getting a serious hype push, maybe we'll get=
<br>
to something open, useful, and RESTful in the next couple of years.<div cla=
ss><br>
<br>
> Keeping session state has traditionally been regarded as a hindrance t=
o<br>
> scalability. Has technology advanced so much, eg with asynchronous,<br=
>
> event-driven ("reactive") servers, that this is no longer a =
problem?<br>
<br></div>
just a question of cost. different protocols have different solutions <br>
(PuSH subscriptions time out automatically, sMAP subscriptions never <br>
time out), based on different scenarios. anything push-based is more <br>
expensive than pure pull, because services/hubs need to keep track of <br>
subscribers. but if the cost is smaller that the benefit, then this will <b=
r>
happen one way or another.<div class><br>
<br>
> Frankly, I'm lacking experience with systems where this kind of<br=
>
> scalability would be required, so I'd happily use persistent<br>
> connections, at least to begin with. Nonetheless, I'm interested i=
n your<br>
> insights.<br>
<br></div>
web of things scenarios simply cannot work with long polling. if you <br>
want to be connected to thousands of sensors in your building to figure <br=
>
out when one is telling you that there is a fire, then you cannot have <br>
open connections to all of them. the answer here is a layered <br>
architecture, maybe some of it hidden as implementation details (sensors <b=
r>
just speaking MQTT to a hub), and other things exposed on the web level <br=
>
(you being able to subscribe to that hub and get alerts). many solutions <b=
r>
have been built around this general pattern, but so far we lack a single <b=
r>
and coherent answer where to draw the boundary between the <br>
implementation details and the open part, and what we should use for <br>
that open part. as mentioned above, maybe that workshop will bring <br>
together enough interested parties to start working on that issue.<br>
<br>
cheers,<br>
<br>
dret.<br>
<br>
-- <br>
erik wilde | mailto:<a href=3D"mailto:[email protected]" target=3D"_blank">=
[email protected]</a> - tel:<a href=3D"tel:%2B1-510-2061079" value=3D"+15=
102061079" target=3D"_blank">+1-510-2061079</a> |<br>
| UC Berkeley - School of Information (ISchool) |<br>
| <a href=3D"http://dret.net/netdret" target=3D"_blank">http://=
dret.net/netdret</a> <a href=3D"http://twitter.com/dret" target=3D"_blank">=
http://twitter.com/dret</a> |<br>
<p></p>
</div>
=20=20=20=20=20
=20=20=20=20
<div style=3D"color:rgb(255,255,255);min-height:0px;"></div>
</div>
=20=20
</div></div></blockquote></div><br></div></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>
<div id=3D"fromDMARC" style=3D"margin-top: 10px;">
<hr style=3D"height:2px ; border-width:0; color:#E3E3E3; background=
-color:#E3E3E3;">
Posted by: Dong Liu <[email protected]> <hr style=3D"=
height:2px ; border-width:0; color:#E3E3E3; background-color:#E3E3E3;">
</div>
<div style=3D"clear:both"> </div>
<table cellspacing=3D4px style=3D"margin-top: 10px; 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/19656;_ylc=3DX3oDMTJxa3VwYTFiBF9TAzk3MzU5NzE0BGdycElkAzQzMTkyNTUEZ3J=
wc3BJZAMxNzA1NzAxMDE0BG1zZ0lkAzE5NjU2BHNlYwNmdHIEc2xrA3JwbHkEc3RpbWUDMTQwMD=
g1NTk2Ng--?act=3Dreply&messageNum=3D19656">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%5Brest-=
discuss%5D%20Reactive%20REST" style=3D"text-decoration: none; color: #2D50F=
D;">
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=3DX3oDMTJlZTdtaDB2BF9TAzk3MzU5NzE0BGdycElkAzQzMTky=
NTUEZ3Jwc3BJZAMxNzA1NzAxMDE0BHNlYwNmdHIEc2xrA250cGMEc3RpbWUDMTQwMDg1NTk2Ng-=
-" 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=3DX3oDMTM2Nm1ndnIwBF9TAzk3MzU5=
NzE0BGdycElkAzQzMTkyNTUEZ3Jwc3BJZAMxNzA1NzAxMDE0BG1zZ0lkAzE5NjU2BHNlYwNmdHI=
Ec2xrA3Z0cGMEc3RpbWUDMTQwMDg1NTk2NgR0cGNJZAMxOTY0Mw--" style=3D"text-decora=
tion: none; color: #2D50FD;">Messages in this topic</a>
(14)
</td>
</tr>
</tbody>
</table>
=20=20=20=20=20=20=20=20
<!------- 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=3DX3oDMTJlYTRxYmVlBF9TAzk3MzU5NzE0BGdycElkAzQzMTkyNTUEZ3Jwc3BJ=
ZAMxNzA1NzAxMDE0BHNlYwN2dGwEc2xrA3ZnaHAEc3RpbWUDMTQwMDg1NTk2Ng--" 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=3DX3oDMTJkNWVndWVhBF9TAzk3ND=
c2NTkwBGdycElkAzQzMTkyNTUEZ3Jwc3BJZAMxNzA1NzAxMDE0BHNlYwNmdHIEc2xrA2dmcARzd=
GltZQMxNDAwODU1OTY2" 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=3D19656/stime=3D1400855966" 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" 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 -->
--047d7bdc1bd03327e604fa123236--