Re: Reactive REST
"Philippe Marsteau [email protected] [rest-discuss]" <[email protected]> Mon, 19 May 2014 09:49:21 -0400
| Newsgroups | gmane.comp.web.services.rest |
|---|---|
| Message-ID | <[email protected]> |
--537a0be1_327b23c6_212 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable FWIW, HTTP is an APPLICATION (transfer) protocol and not a TRANPORT protoco= l. TCP is the transport protocol HTTP uses. I think the benefits of REST ar= chitectural style over Pub/Sub style is the scalability associated to not r= equire servers to keep tracks of clients. The statelessness constraint mean= s a 2nd calls of a client shouldn't/mustn'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 load balancing solutions w/o sharing or d= istributing caches) without any impacts for the clients open "sessions" (fr= om a client perspective). To achieve this, any input that a second call nee= ds following 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 t= o client. Because the client determines lifecycle of these "push config" dy= namic resources, eg when to delete it, that data need to be kept in sync be= tween machines, and handling* that extra state breaks 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 reduce= s scalability of such model (basically each client must be seen as a server= and vice-versa). The clients costs is typically higher than server (client= s 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 ser= ver as a result. Finally, pub/sub model implies a level of trusts normal H= TTP app servers do not need to have. Blindly connecting to any HTTP endpoin= t opens to security vulnerabilities. The client (subscriber) will typically= expect some shared secret or key cert exchange, and the server may not be = willing to blindly post data to unknown locations. Hope this helps. Intere= sting 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 describin= g REST style; refer to it to compare the constraints with one another, and = why he believed REST style was better suited for scalability.=20=20=20=20=20 ---Phil On May 19, 2014 at 2:55:29 AM EDT, Hubert A Le Van Gong [email protected]= [rest-discuss] <[email protected]> wrote: =C2=A0 Hi Michae= l, 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 level = (transport) than the actual resource management and the stateless principle= s associated to it? In the same vein, would you also consider one cannot de= fine a RESTful service over persistent HTTPS connections for instance? Be= st, Hubert On May 18, 2014, at 8:02 AM, Michael Schuerig michael.lists@sch= uerig.de [rest-discuss] <[email protected]> wrote: On Saturday 1= 7 May 2014 18:15:13 Erik [email protected]=C2=A0[rest-discuss] w= rote:> i guess i am having trouble with looking at a connection as a resour= ce> with state (unless you talk about network monitoring and management> sc= enarios, which are an entirely different beast).No, a connection isn't a re= source. But keeping a connection open from=C2=A0each client to the server p= uts a strain on the server. Ideally, a=C2=A0RESTful service is loaded only = "dynamically" in the sense that the=C2=A0("static") number of clients is ir= relevant, what counts is the=C2=A0("dynamic") number of requests per unit o= f time. My understanding of=C2=A0REST is that this is deliberate and very h= elpful for scalability. Open=C2=A0connections are a strain on a service eve= n in the absence of any=C2=A0requests. For one thing, a single server can o= nly manage a limited=C2=A0number of open connections at a time.In REST, at = least as far as I understand it(!), state is only supposed=C2=A0to figure a= s transferred resource state; session state is prohibited.My understanding = may be wrong and I'm perfectly willing to tone down the=C2=A0RESTful ideal = for practical purposes. The point I'm trying to make is=C2=A0purely a matte= r of classification, ie that I think persistent=C2=A0connections are not RE= STful.> 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 tha= t 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, wh= ereas for push that state needs> to be maintained, which is expensive.So, i= s "reverse REST" still RESTful? Yes, the individual push request=C2=A0from = server to client probably qualifies. The architecture as a whole=C2=A0proba= bly doesn't. As you write, state needs to be maintained which=C2=A0hinders = scalability.A truly RESTful solution would have to do without such state. *= I* don't=C2=A0see how that is possible, but that's why I started this discu= ssion.Also, I'd like to repeat that I don't mean not being RESTful, or not= =C2=A0being reactive, as some kind of condemnation. Both approaches offer v= ery=C2=A0sensible advice in general, I'm interested in seeing how well they= fit=C2=A0together.[...]> >> a push model. there are a variety of push prot= ocols (PuSH, MQTT,> >> APN,> >> C2DM, sMAP) out there, but none so far has = taken over the world.> >=C2=A0> > 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?>=C2=A0> these = are two very different questions. they work very well in> practice, for exa= mple across all iOS devices (APN), across all> android devices (C2DM), in b= uilding automation scenarios (sMAP), or> in large sensor network settings (= MQTT).=C2=A0OK, I take these as existence proofs that push works in practic= e.> they all come with different> design goals and constraints, and it seem= s that you have something> specific in mind as well. as long as you don't b= etter understand the> specific constraints of the scenario you have in mind= , picking a> solution (or writing down the requirements for a new one) prob= ably> will be hard.Right now I'm not trying to do anything, I'm first and f= oremost trying=C2=A0to understand the landscape. As a consequence, my speci= fic questions=C2=A0keep changing. My starting point was the question "What = would a=C2=A0'reactive' and RESTful web application look like from browser = through=C2=A0app server to database". Especially when it comes to the commu= nication=C2=A0between browser (or rather JavaScript-client) and app server,= I don't=C2=A0see how to reconcile statelessness and event-drivenness.Micha= el--=C2=A0Michael Schuerigmailto:[email protected]://www.schuerig.de/= michael/ = =20 --537a0be1_327b23c6_212 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> <html> <head> </head> <body style="background-color: #fff;"> <span style="display:none"> </span> <!--~-|**|PrettyHtmlStartT|**|-~--> <div id="ygrp-mlmsg" style="position:relative;"> <div id="ygrp-msg" style="z-index: 1;"> <!--~-|**|PrettyHtmlEndT|**|-~--> <div id="ygrp-text" > <p>FWIW, HTTP is an APPLICATION (transfer) protocol and not a TRANPORT protocol. TCP is the transport protocol HTTP uses.<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. The statelessness constraint means a 2nd calls of a client shouldn't/mustn'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 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 following a first c all should be transferred to client after each call (state is transfered to client instead of kept on server).</div><div><br></div><div>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 need to be kept in sync between machines, and handling* that extra state breaks statelessness of REST (*handling like in auto-expiring subscriptions over time, etc.)</div><div><br></div><div>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 w hitelisting to let calls come in. That further reduces scalability of such model (basically each client must be seen as a server and vice-versa). The clients costs is typically higher 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.</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 endpoint opens to security vulnerabilities. The client (subscriber) will typically expect some shared secret or key cert exchang e, and the server may not be willing to blindly post data to unknown locations.</div><div><br></div><div>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.</div><div><br><div id="boxer-meta"></div><div id="attachments"></div></div><span id="draft-break"></span>---<br>Phil<span id="draft-break"></span><div><div>On May 19, 2014 at 2:55:29 AM EDT, Hubert A Le Van Gong [email protected] [rest-discuss] <[email protected]> wrote:<br><blockquote ty pe="cite"><div> <span> </span> <div id="ygrp-text"> <p>Hi Michael,</p><div><br></div><div>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 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="mailto:[email protected]">[email protected]</a> [rest-discuss] <<a href="mailto:[email protected]">[email protected]</a>> wrote:</div><br><blockquote type="cite"><div style="font -family: Helvetica;font-size: 12px;font-style: normal;font-variant: normal;font-weight: normal;letter-spacing: normal;text-align: start;text-indent: 0px;text-transform: none;white-space: normal;"><div id="ygrp-mlmsg" style="font-size: 13px;font-family: Arial, helvetica, clean, sans-serif;"><div id="ygrp-msg"><div id="ygrp-text" style="font-family: Georgia;"><p style="margin: 0px 0px 1em;">On Saturday 17 May 2014 18:15:13 Erik Wilde<span> </span><a href="mailto:[email protected]" style="font-family: Verdana;">[email protected]</a><span> </span>[rest-<br>discuss] wrote:<br><br>> i guess i am having trouble with looking at a connection as a resource<br>> with state (unless you talk about network monitoring and management<br>> scenarios, which are an entirely different bea st).<br><br>No, a connection isn't a resource. But keeping a connection open from<span> </span><br>each client to the server puts a strain on the server. Ideally, a<span> </span><br>RESTful service is loaded only "dynamically" in the sense that the<span> </span><br>("static") number of clients is irrelevant, what counts is the<span> </span><br>("dynamic") number of requests per unit of time. My understanding of<span> </span><br>REST is that this is deliberate and very helpful for scalability. Open<span> </span><br>connections are a strain on a service even in the absence of any<span> </span><br>requests. For one thing, a single server can only manage a limited<span> </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> </span><br>to figure as transferred resource state; session state is prohibited.<br><br>My understanding may be wrong and I'm perfectly willing to tone down the<span> </span><br>RESTful ideal for practical purposes. The point I'm trying to make is<span> </span><br>purely a matter of classification, ie that I think persistent<span> </span><br>connections are not RESTful.<br><br>> but it is entirely possible 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 become the<br>> resource to be pushed to, i.e. your re source needs to be known by the<br>> event source. there are tons of PubSub approaches out there, only<br>> 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, sources<br>> don't need to know the consumers, whereas for push that state needs<br>> to be maintained, which is expensive.<br><br>So, is "reverse REST" still RESTful? Yes, the individual push request<span> </span><br>from server to client probably qualifies. The architecture as a whole<span> </span><br>probably doesn't. As you write, state needs to be maintained which<span> </span><br>hinders scalability.<br><br>A truly RESTful solution would have to do without such state. *I* don't<span> </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, or not<span> </span><br>being reactive, as some kind of condemnation. Both approaches offer very<span> </span><br>sensible advice in general, I'm interested in seeing how well they fit<span> </span><br>together.<br><br>[...]<br>> >> a push model. there are a variety of push protocols (PuSH, MQTT,<br>> >> APN,<br>> >> C2DM, sMAP) out there, but none so far has taken over the world.<br>> ><span> </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> </span><br>> these are two very different questions. they work very well in<br>> practice, for example across all iOS devices (APN), across all<br>> android devices (C2DM), in building automation scenarios (sMAP), or<br>> in large sensor network settings (MQTT).<span> </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 seems that you have something<br>> specific in mind as well. as long as you don't better understand the<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'm fir st and foremost trying<span> </span><br>to understand the landscape. As a consequence, my specific questions<span> </span><br>keep changing. My starting point was the question "What would a<span> </span><br>'reactive' and RESTful web application look like from browser through<span> </span><br>app server to database". Especially when it comes to the communication<span> </span><br>between browser (or rather JavaScript-client) and app server, I don't<span> </span><br>see how to reconcile statelessness and event-drivenness.<br><br>Michael<br><br>--<span> </span><br>Michael Schuerig<br><a href="mailto:[email protected]" style="font-family: Verdana;">mailto:[email protected]</a><br><a href="http://www.schuerig.de/michael/" style="font-family: Verdana;">ht tp://www.schuerig.de/michael/</a><br><br></p></div></div></div></div></blockquote></div><br></div><p></p> </div> <!-- end group email --> </div></blockquote></div></div></p> </div> <!--~-|**|PrettyHtmlStart|**|-~--> <div style="color: #fff; height: 0;">__._,_.___</div> <div style="clear:both"> </div> <table cellspacing=4px style="margin-top: 20px; margin-bottom: 10px; color: #2D50FD;"> <tbody> <tr> <td style="font-size: 12px; font-family: arial; font-weight: bold; padding: 7px 5px 5px;" > <a style="text-decoration: none; color: #2D50FD" href="https://groups.yahoo.com/neo/groups/rest-discuss/conversations/messages/19650;_ylc=X3oDMTJxZGpjZjhzBF9TAzk3MzU5NzE0BGdycElkAzQzMTkyNTUEZ3Jwc3BJZAMxNzA1NzAxMDE0BG1zZ0lkAzE5NjUwBHNlYwNmdHIEc2xrA3JwbHkEc3RpbWUDMTQwMDUwNzM2NA--?act=reply&messageNum=19650">Reply via web post</a> </td> <td>•</td> <td style="font-size: 12px; font-family: arial; padding: 7px 5px 5px;" > <a href="mailto:[email protected]?subject=Re%3A%20%5Brest-discuss%5D%20Reactive%20REST" style="text-decoration: none; color: #2D50FD;"> Reply to sender </a> </td> <td>•</td> <td style="font-size: 12px; font-family: arial; padding: 7px 5px 5px;"> <a href="mailto:[email protected]?subject=Re%3A%20%5Brest-discuss%5D%20Reactive%20REST" style="text-decoration: none; color: #2D50FD"> Reply to group </a> </td> <td>•</td> <td style="font-size: 12px; font-family: arial; padding: 7px 5px 5px;" > <a href="https://groups.yahoo.com/neo/groups/rest-discuss/conversations/newtopic;_ylc=X3oDMTJlOXNubjNrBF9TAzk3MzU5NzE0BGdycElkAzQzMTkyNTUEZ3Jwc3BJZAMxNzA1NzAxMDE0BHNlYwNmdHIEc2xrA250cGMEc3RpbWUDMTQwMDUwNzM2NA--" style="text-decoration: none; color: #2D50FD">Start a New Topic</a> </td> <td>•</td> <td style="font-size: 12px; font-family: arial; padding: 7px 5px 5px;color: #2D50FD;" > <a href="https://groups.yahoo.com/neo/groups/rest-discuss/conversations/topics/19643;_ylc=X3oDMTM2aWlxcm8yBF9TAzk3MzU5NzE0BGdycElkAzQzMTkyNTUEZ3Jwc3BJZAMxNzA1NzAxMDE0BG1zZ0lkAzE5NjUwBHNlYwNmdHIEc2xrA3Z0cGMEc3RpbWUDMTQwMDUwNzM2NAR0cGNJZAMxOTY0Mw--" style="text-decoration: none; color: #2D50FD;">Messages in this topic</a> (8) </td> </tr> </tbody> </table> <div id="megaphoneModule"> <hr style="height:2px ; border-width:0; color:#E3E3E3; background-color:#E3E3E3;"> <div> <div class="feature_intro"> <div style="background-color:white;padding:0px 10px;"> <div class="header" style="margin-right:10px;display:inline-block;width:400px;"> <a rel="nofollow" style="text-decoration:none;" target="_blank" href="https://groups.yahoo.com/neo;_ylc=X3oDMTExc2JuanI3BF9TAzk3MzU5NzE0BGNmMTADQ1AEc2VjA21lZ2FwaG9uZQ--"><div style="font-size:15px;line-height:20px;color:blue;">Just launched ! Link preview on Yahoo Groups</div></a> <div class="snippet" style="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="display:inline-block;vertical-align:top;margin-top:10px;"> <a rel="nofollow" target="_blank" href="http://yahoogroups.tumblr.com/post/85014546066/bye-bye-blue-links-welcome-link-preview" name="lm_btn_url" style="text-decoration:none;"> <input type="button" class="lm-btn" value="Learn more" style="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="lm_btn"> </a> <a rel="nofollow" target="_blank" href="https://groups.yahoo.com/neo;_ylc=X3oDMTExc2JuanI3BF9TAzk3MzU5NzE0BGNmMTADQ1AEc2VjA21lZ2FwaG9uZQ--" name="try_btn_url" style="text-decoration:none;"> <input type="button" class="try-btn" value="Try it now" style="font-size:14px;vertical-align:middle;height:30px;cursor:pointer;margin-bottom:10px;width:100px;background-color:rgb(250, 250, 250);" name="try_btn"> </a> </div> </div> </div> </div> <hr style="height:2px ; border-width:0; color:#E3E3E3; background-color:#E3E3E3;"> </div> <!------- Start Nav Bar ------> <!-- |**|begin egp html banner|**| --> <div id="ygrp-vital" style="background-color: #f2f2f2; font-family: Verdana; font-size: 10px; margin-bottom: 10px; padding: 10px;"> <span id="vithd" style="font-weight: bold; color: #333; text-transform: uppercase; "><a href="https://groups.yahoo.com/neo/groups/rest-discuss/info;_ylc=X3oDMTJlZDZib2tzBF9TAzk3MzU5NzE0BGdycElkAzQzMTkyNTUEZ3Jwc3BJZAMxNzA1NzAxMDE0BHNlYwN2dGwEc2xrA3ZnaHAEc3RpbWUDMTQwMDUwNzM2NA--" style="text-decoration: none;">Visit Your Group</a></span> <ul style="list-style-type: none; margin: 0; padding: 0; display: inline;"> </ul> </div> <div id="ft" style="font-family: Arial; font-size: 11px; margin-top: 5px; padding: 0 2px 0 0; clear: both;"> <a href="https://groups.yahoo.com/neo;_ylc=X3oDMTJkNWE2bjBtBF9TAzk3NDc2NTkwBGdycElkAzQzMTkyNTUEZ3Jwc3BJZAMxNzA1NzAxMDE0BHNlYwNmdHIEc2xrA2dmcARzdGltZQMxNDAwNTA3MzY0" style="float: left;"><img src="http://l.yimg.com/ru/static/images/yg/img/email/new_logo/logo-groups-137x15.png" height="15" width="137" alt="Yahoo! Groups" style="border: 0;"/></a> <div style="color: #747575; float: right;"> • <a href="https://info.yahoo.com/privacy/us/yahoo/groups/details.html" style="text-decoration: none;">Privacy</a> • <a href="mailto:[email protected]?subject=Unsubscribe" style="text-decoration: none;">Unsubscribe</a> • <a href="https://info.yahoo.com/legal/us/yahoo/utos/terms/" style="text-decoration: none;">Terms of Use</a> </div> </div> <br> <!-- |**|end egp html banner|**| --> </div> <!-- ygrp-msg --> <!-- Sponsor --> <!-- |**|begin egp html banner|**| --> <div id="ygrp-sponsor" style="width:160px; float:right; clear:none; margin:0 0 25px 0; background: #fff;"> <!-- Start Recommendations --> <div id="ygrp-reco"> </div> <!-- End Recommendations --> </div> <!-- |**|end egp html banner|**| --> <div style="clear:both; color: #FFF; font-size:1px;">.</div> </div> <img src="http://geo.yahoo.com/serv?s=97359714/grpId=4319255/grpspId=1705701014/msgId=19650/stime=1400507364" width="1" height="1"> <br> <img src="http://y.analytics.yahoo.com/fpc.pl?ywarid=515FB27823A7407E&a=10001310322279&js=no&resp=img&cf10=CP" width="1" height="1"> <div style="color: #fff; height: 0;">__,_._,___</div> <!--~-|**|PrettyHtmlEnd|**|-~--> </body> <!--~-|**|PrettyHtmlStart|**|-~--> <head> <style type="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; } 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.file-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; } #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; } --> </style> </head> <!--~-|**|PrettyHtmlEnd|**|-~--> </html> <!-- end group email --> --537a0be1_327b23c6_212--