| Newsgroups |
gmane.comp.web.services.rest |
| Message-ID |
<CAAgVzdikqk0rkxJ50LjmMDg+dgML73=0bYVvTuV7fsS8xgFZ6A@mail.gmail.com> |
---BADzCkeukVZvARYgWZj6eXKrNU5wL1vXA8VLs7
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
In that case, I assume the use may always have the current states of
the lights as far as the control interface is on. So the states can be
pushed to the user's interface.
On Wed, Jul 9, 2014 at 3:19 PM, Simpson, Robby (GE Energy Management)
<[email protected]> wrote:
> From a design perspective, I prefer a conditional PUT as well.
>
> Unfortunately, latency is a major issue with wireless lighting (i.e., use=
rs do not want to notice any delay) and there is a perception that having t=
o have a GET before a PUT would introduce too much latency. Especially in =
scenarios where there are multiple lights (multicast).
>
> - Robby
>
> From: "Dong Liu [email protected]<mailto:[email protected]> [rest-discu=
ss]" <[email protected]<mailto:rest-discuss-noreply@yaho=
ogroups.com>>
> Reply-To: Dong Liu <[email protected]<mailto:[email protected]>>
> Date: Wednesday, July 9, 2014 at 3:09 PM
> To: Will Hartung <[email protected]<mailto:[email protected]>>
> Cc: Rest List <[email protected]<mailto:rest-discuss@yahoogrou=
ps.com>>
> Subject: Re: [rest-discuss] RESTful Toggle
>
>
>
> For a three-way or N-way switch, I prefer a conditional PUT to a POST.
>
> Cheers,
>
> Dong
>
>
> On Wed, Jul 9, 2014 at 2:45 PM, Will Hartung [email protected]<mailto:w=
[email protected]> [rest-discuss] <[email protected]<ma=
ilto:[email protected]>> wrote:
>
>
> From home automation point of view, I can only think of one use case wher=
e "toggle" actually has any validity, and that would be in the "3 way switc=
h" scenario.
>
> A 3 way switch is exemplified by walking up to a dark hallway, turning th=
e light on with a nearby swtich, walking to the end, and then turning the l=
ight off with a switch at the other end.
>
> This use case is a true "toggle", since the "state" is the actual light (=
on or off), and the switch itself does not represent that state (unlike a n=
ormal, single switch). The switches can be "up" or "down" unrelated to the =
light being "on" or "off".
>
> Given that, again from a home automation point of view, I can't really ev=
er see "toggle" as a viable action. Maybe it's a primitive. But, in the end=
, when you walk in to that dark hallway, what you want is the light to go o=
n, the mechanics of the switches are secondary.
>
> I just mention this because at a high level, "toggle" doesn't make much s=
ense to me. The automation folks may well need it as a primitive to control=
a switch. But at the "application" level, it doesn't make much sense. At a=
n application level, you either want the "Light" ON or OFF.
>
> So, with that consideration, a simple POST will do the trick.
>
> I don't think there's any "race condition", because "toggle" is not a sta=
te, it's an action. If you care about the state, then set the state you wan=
t. You should hide the "toggle", and enforce the state behind the scenes (w=
here you can manage race conditions on the server). Let the server decide t=
hat when you change the state to ON, it can determine, internally, if the d=
evice is OFF and then send a TOGGLE command to make it ON. If it's already =
ON, then nothing happens.
>
> But a "toggle" POST is just that, a simple command.
>
> Regards,
>
> Will Hartung
> ([email protected]<mailto:[email protected]>)
>
>
>
>
> On Wed, Jul 9, 2014 at 9:36 AM, Erik Wilde [email protected]<mailto:dret@=
berkeley.edu> [rest-discuss] <[email protected]<mailto:r=
[email protected]>> wrote:
>
>
> hello robby.
>
> On 2014-07-09, 17:47 , 'Simpson, Robby (GE Energy Management)'
>
> [email protected]<mailto:[email protected]> [rest-discuss] wrote:
>>> it sounds like the scenario we were talking about, that all you want is
>>> to tell the resource to "reverse its state". in this case, i'd POST a
>>> body that represents this request, in whatever serialization you happen
>>> to prefer. the resource toggles. everybody's happy.
>> OK. Still seems like a bit of a departure from typical RESTful interface=
s
>> I've seen and has the potential to be a catch-all tunnel for RPC-style
>> requests.
>> E.g.:
>> /command, where one could POST all sorts of commands like "toggle."
>
> the problem is not that POST can mean anything (it can), but people
> POSTing things to a "do stuff" resource, which then isn't
> resource-oriented anymore. your RPC sensor shouldn't go off because of
> people POSTing things to resources (that's fine), but because of people
> POSTing things to something other than resources (the "API end point",
> for example).
>
>
>>> but i am confused because you wrote earlier that you were concerned
>>> about race conditions. which seems to imply that instead of just
>>> toggling, you're also assuming that you're "toggling *from* some state"=
.
>>> but that wouldn't be the "blind toggle" we discussed. could you clarify
>>> a bit how exactly the operation that you're trying to design is defined=
?
>> Apologies, a blind toggle is what is desired. As it currently works, in
>> the current binary protocol, a button press on a toggle switch simply
>> sends a "toggle" command.
>
> then how would a race condition enter the picture? just because of the
> timestamp when you last observed the resource's state? or something
> else? to me, toggling always is kind of a game: if somebody toggled
> ahead of you, you'll do something other than you wanted to, but that's
> how it is and you'll have to deal with it after toggling and finding out
> that you switched the damn thing back on again...
>
>
> cheers,
>
> dret.
>
> --
> erik wilde | mailto:[email protected]<mailto:[email protected]> - tel:+1-=
510-2061079<tel:%2B1-510-2061079> |
> | UC Berkeley - School of Information (ISchool) |
> | http://dret.net/netdret http://twitter.com/dret |
>
>
> CONFIDENTIALITY NOTICE: The information contained in this electronic tran=
smission may be confidential. If you are not an intended recipient, be awar=
e that any disclosure, copying, distribution or use of the information cont=
ained in this transmission is prohibited and may be unlawful. If you have r=
eceived this transmission in error, please notify us by email reply and the=
n erase it from your computer system.
>
>
>=20
---BADzCkeukVZvARYgWZj6eXKrNU5wL1vXA8VLs7
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>In that case, I assume the use may always have the current states of<br>
the lights as far as the control interface is on. So the states can be<br>
pushed to the user's interface.<br>
<br>
On Wed, Jul 9, 2014 at 3:19 PM, Simpson, Robby (GE Energy Management)<br>
<[email protected]> wrote:<br>
> From a design perspective, I prefer a conditional PUT as well.<br>
><br>
> Unfortunately, latency is a major issue with wireless lighting (i.e., users do not want to notice any delay) and there is a perception that having to have a GET before a PUT would introduce too much latency. Especially in scenarios where there are multiple lights (multicast).<br>
><br>
> - Robby<br>
><br>
> From: "Dong Liu [email protected]<mailto:[email protected]> [rest-discuss]" <[email protected]<mailto:[email protected]>><br>
> Reply-To: Dong Liu <[email protected]<mailto:[email protected]>><br>
> Date: Wednesday, July 9, 2014 at 3:09 PM<br>
> To: Will Hartung <[email protected]<mailto:[email protected]>><br>
> Cc: Rest List <[email protected]<mailto:[email protected]>><br>
> Subject: Re: [rest-discuss] RESTful Toggle<br>
><br>
><br>
><br>
> For a three-way or N-way switch, I prefer a conditional PUT to a POST.<br>
><br>
> Cheers,<br>
><br>
> Dong<br>
><br>
><br>
> On Wed, Jul 9, 2014 at 2:45 PM, Will Hartung [email protected]<mailto:[email protected]> [rest-discuss] <[email protected]<mailto:[email protected]>> wrote:<br>
><br>
><br>
> From home automation point of view, I can only think of one use case where "toggle" actually has any validity, and that would be in the "3 way switch" scenario.<br>
><br>
> A 3 way switch is exemplified by walking up to a dark hallway, turning the light on with a nearby swtich, walking to the end, and then turning the light off with a switch at the other end.<br>
><br>
> This use case is a true "toggle", since the "state" is the actual light (on or off), and the switch itself does not represent that state (unlike a normal, single switch). The switches can be "up" or "down" unrelated to the light being "on" or "off".<br>
><br>
> Given that, again from a home automation point of view, I can't really ever see "toggle" as a viable action. Maybe it's a primitive. But, in the end, when you walk in to that dark hallway, what you want is the light to go on, the mechanics of the switches are secondary.<br>
><br>
> I just mention this because at a high level, "toggle" doesn't make much sense to me. The automation folks may well need it as a primitive to control a switch. But at the "application" level, it doesn't make much sense. At an application level, you either want the "Light" ON or OFF.<br>
><br>
> So, with that consideration, a simple POST will do the trick.<br>
><br>
> I don't think there's any "race condition", because "toggle" is not a state, it's an action. If you care about the state, then set the state you want. You should hide the "toggle", and enforce the state behind the scenes (where you can manage race conditions on the server). Let the server decide that when you change the state to ON, it can determine, internally, if the device is OFF and then send a TOGGLE command to make it ON. If it's already ON, then nothing happens.<br>
><br>
> But a "toggle" POST is just that, a simple command.<br>
><br>
> Regards,<br>
><br>
> Will Hartung<br>
> ([email protected]<mailto:[email protected]>)<br>
><br>
><br>
><br>
><br>
> On Wed, Jul 9, 2014 at 9:36 AM, Erik Wilde [email protected]<mailto:[email protected]> [rest-discuss] <[email protected]<mailto:[email protected]>> wrote:<br>
><br>
><br>
> hello robby.<br>
><br>
> On 2014-07-09, 17:47 , 'Simpson, Robby (GE Energy Management)'<br>
><br>
> [email protected]<mailto:[email protected]> [rest-discuss] wrote:<br>
>>> it sounds like the scenario we were talking about, that all you want is<br>
>>> to tell the resource to "reverse its state". in this case, i'd POST a<br>
>>> body that represents this request, in whatever serialization you happen<br>
>>> to prefer. the resource toggles. everybody's happy.<br>
>> OK. Still seems like a bit of a departure from typical RESTful interfaces<br>
>> I've seen and has the potential to be a catch-all tunnel for RPC-style<br>
>> requests.<br>
>> E.g.:<br>
>> /command, where one could POST all sorts of commands like "toggle."<br>
><br>
> the problem is not that POST can mean anything (it can), but people<br>
> POSTing things to a "do stuff" resource, which then isn't<br>
> resource-oriented anymore. your RPC sensor shouldn't go off because of<br>
> people POSTing things to resources (that's fine), but because of people<br>
> POSTing things to something other than resources (the "API end point",<br>
> for example).<br>
><br>
><br>
>>> but i am confused because you wrote earlier that you were concerned<br>
>>> about race conditions. which seems to imply that instead of just<br>
>>> toggling, you're also assuming that you're "toggling *from* some state".<br>
>>> but that wouldn't be the "blind toggle" we discussed. could you clarify<br>
>>> a bit how exactly the operation that you're trying to design is defined?<br>
>> Apologies, a blind toggle is what is desired. As it currently works, in<br>
>> the current binary protocol, a button press on a toggle switch simply<br>
>> sends a "toggle" command.<br>
><br>
> then how would a race condition enter the picture? just because of the<br>
> timestamp when you last observed the resource's state? or something<br>
> else? to me, toggling always is kind of a game: if somebody toggled<br>
> ahead of you, you'll do something other than you wanted to, but that's<br>
> how it is and you'll have to deal with it after toggling and finding out<br>
> that you switched the damn thing back on again...<br>
><br>
><br>
> cheers,<br>
><br>
> dret.<br>
><br>
> --<br>
> erik wilde | mailto:[email protected]<mailto:[email protected]> - tel:+1-510-2061079<tel:%2B1-510-2061079> |<br>
> | UC Berkeley - School of Information (ISchool) |<br>
> | http://dret.net/netdret http://twitter.com/dret |<br>
><br>
><br>
> CONFIDENTIALITY NOTICE: The information contained in this electronic transmission may be confidential. If you are not an intended recipient, be aware that any disclosure, copying, distribution or use of the information contained in this transmission is prohibited and may be unlawful. If you have received this transmission in error, please notify us by email reply and then erase it from your computer system.<br>
><br>
><br>
> <br>
</p>
</div>
<!--~-|**|PrettyHtmlStart|**|-~-->
<div style="color: #fff; height: 0;">__._,_.___</div>
<div style="clear:both"> </div>
<div id="fromDMARC" style="margin-top: 10px;">
<hr style="height:2px ; border-width:0; color:#E3E3E3; background-color:#E3E3E3;">
Posted by: Dong Liu <[email protected]> <hr style="height:2px ; border-width:0; color:#E3E3E3; background-color:#E3E3E3;">
</div>
<div style="clear:both"> </div>
<table cellspacing=4px style="margin-top: 10px; 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/19686;_ylc=X3oDMTJxdTF2bGJpBF9TAzk3MzU5NzE0BGdycElkAzQzMTkyNTUEZ3Jwc3BJZAMxNzA1NzAxMDE0BG1zZ0lkAzE5Njg2BHNlYwNmdHIEc2xrA3JwbHkEc3RpbWUDMTQwNDkzMzc3OA--?act=reply&messageNum=19686">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%20RESTful%20Toggle" 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%20RESTful%20Toggle" 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=X3oDMTJla3JoYjVmBF9TAzk3MzU5NzE0BGdycElkAzQzMTkyNTUEZ3Jwc3BJZAMxNzA1NzAxMDE0BHNlYwNmdHIEc2xrA250cGMEc3RpbWUDMTQwNDkzMzc3OA--" 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/19657;_ylc=X3oDMTM2YmVlaTRmBF9TAzk3MzU5NzE0BGdycElkAzQzMTkyNTUEZ3Jwc3BJZAMxNzA1NzAxMDE0BG1zZ0lkAzE5Njg2BHNlYwNmdHIEc2xrA3Z0cGMEc3RpbWUDMTQwNDkzMzc3OAR0cGNJZAMxOTY1Nw--" style="text-decoration: none; color: #2D50FD;">Messages in this topic</a>
(30)
</td>
</tr>
</tbody>
</table>
<!------- 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=X3oDMTJlcDJmdDd1BF9TAzk3MzU5NzE0BGdycElkAzQzMTkyNTUEZ3Jwc3BJZAMxNzA1NzAxMDE0BHNlYwN2dGwEc2xrA3ZnaHAEc3RpbWUDMTQwNDkzMzc3OA--" style="text-decoration: none;">Visit Your Group</a></span>
<ul style="list-style-type: none; margin: 0; padding: 0; display: inline;">
<li style="border-right: 1px solid #000; font-weight: 700; display: inline; padding: 0 5px; margin-left: 0;">
<span class="cat"><a href="https://groups.yahoo.com/neo/groups/rest-discuss/members/all;_ylc=X3oDMTJmZWY0MHA3BF9TAzk3MzU5NzE0BGdycElkAzQzMTkyNTUEZ3Jwc3BJZAMxNzA1NzAxMDE0BHNlYwN2dGwEc2xrA3ZtYnJzBHN0aW1lAzE0MDQ5MzM3Nzg-" style="text-decoration: none;">New Members</a></span>
<span class="ct" style="color: #ff7900;">3</span>
</li>
</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=X3oDMTJkMjhvanViBF9TAzk3MzU5NzE0BGdycElkAzQzMTkyNTUEZ3Jwc3BJZAMxNzA1NzAxMDE0BHNlYwNmdHIEc2xrA2dmcARzdGltZQMxNDA0OTMzNzc4" 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=19686/stime=1404933778" width="1" height="1"> <br>
<img src="http://y.analytics.yahoo.com/fpc.pl?ywarid=515FB27823A7407E&a=10001310322279&js=no&resp=img" 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 -->
---BADzCkeukVZvARYgWZj6eXKrNU5wL1vXA8VLs7--