<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Apr 30, 2015 at 3:03 PM, Joshua Colp <span dir="ltr"><<a href="mailto:jcolp@digium.com" target="_blank" onclick="window.open('https://mail.google.com/mail/?view=cm&tf=1&to=jcolp@digium.com&cc=&bcc=&su=&body=','_blank','location=yes,menubar=yes,resizable=yes,width=800,height=600');return false;">jcolp@digium.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">George Joseph wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
<br>
On Thu, Apr 30, 2015 at 2:01 PM, Joshua Colp <<a href="mailto:jcolp@digium.com" target="_blank" onclick="window.open('https://mail.google.com/mail/?view=cm&tf=1&to=jcolp@digium.com&cc=&bcc=&su=&body=','_blank','location=yes,menubar=yes,resizable=yes,width=800,height=600');return false;">jcolp@digium.com</a><br>
<mailto:<a href="mailto:jcolp@digium.com" target="_blank" onclick="window.open('https://mail.google.com/mail/?view=cm&tf=1&to=jcolp@digium.com&cc=&bcc=&su=&body=','_blank','location=yes,menubar=yes,resizable=yes,width=800,height=600');return false;">jcolp@digium.com</a>>> wrote:<br>
<br>
George Joseph wrote:<br>
<br>
<br></blockquote></blockquote><div><snip> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>
What if contacts are stored in an external database? Your proposal<br>
would also have them going there as well. This would require an<br>
explanation for deployers to know what is going on exactly and what<br>
they are. As well this means there would be a period of time where<br>
the permanent contacts would not be present if other instances are<br>
sharing the same database and one restarts.<br>
<br>
<br>
They can't be today can they? The dynamic ones are explicitly mapped to<br>
astdb and the permanent ones are explicitly placed in the aor based<br>
container. Can you even use sorcery.conf to map contacts somewhere else<br>
given that they're just strings in an aor?<br>
</blockquote>
<br>
You sure can.<br>
<br></blockquote><div><br></div><div>Who would even know they can do that besides you? :)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<snip><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
A contact is updated when the registration is refreshed, you have to<br>
persist that out to disk or if a restart occurs it'll be expired.<br>
<br>
<br>
Yes, so for dynamic contacts, the expiration would be written with the<br>
normal update and for status and rtt changes, with update_temp.<br>
</blockquote>
<br>
I experimented with doing this when sorcery was originally, partitioning an object to exist in multiple places. It was not easy to get it right.<br></blockquote><div><br></div><div>I've done this a number of times for large OLTP systems where there's data you want in a scratchpad that may nor may not ever be persisted. If it's implemented at the correct layer, it becomes invisible.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
<br>
For permanent contacts, we do the same except we call<br>
ast_sorcery_create_temp and ast_sorcery_delete_temp so they<br>
never get<br>
persisted to astdb.<br>
<br>
<br>
So. This is what I was originally trying to express when you did the<br>
wizard work, you've just gone about it in a different manner. I<br>
think this is a rather specialized addition that could be done in a<br>
better way.<br>
<br>
Right now sorcery wizards can't be programmatically added. They just<br>
can't. You have to do it from the sorcery.conf configuration file.<br>
<br>
<br>
Not true. ast_sorcery_apply_wizard_mapping allows yo to add a wizard to<br>
any object type at run time. That's what the config_wizard does. When<br>
the object type registers, it adds a memory wizard to the object type's<br>
wizard list. The config wizard then manipulates the memory wizard.<br>
</blockquote>
<br>
It adds a wizard but does not return a handle to it. It also doesn't allow you to specify where to place it. It's always at the end.<br></blockquote><div><br></div><div>You don't need a handle, you have the wizard itself. Correct on the order.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
<br>
What if they could be?<br>
What if you could add a wizard that's marked as caching (so it's<br>
only queried) but still have a handle to it to create/update/destroy?<br>
<br>
<br>
You just described res_pjsip_config_wizard exactly.<br>
</blockquote>
<br>
Yes, except without having a direct handle and more control over things you had to do it in an indirect manner.<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
<br>
Wrap that up in a higher level API like you want above and you<br>
extend sorcery in a way that's useful in multiple ways.<br>
<br>
<br>
Put the whole mutability thing aside for a minute. I guess what I'm<br>
suggesting that the default sorcery behavior could be an automatic<br>
read/write cache in front of every sorcery wizard. You can then control<br>
whether how writes are handled (if at all) by options you give when you<br>
register the object type, and options you give on CRUD calls.<br>
</blockquote>
<br>
I'm not a fan of automatic anything or complicating the sorcery core any further. Higher level stuff built on top which has to be explicitly done by users, yes.<br></blockquote><div><br></div><div>I think that's true in some cases but in others, you don't want "users" doing it 50 different ways where something carefully crafted at a lower level will do the trick.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
For my contact scenario, I'd say writable cache and a writable back end<br>
(astdb by default). When writing a new dynamic contact or updating the<br>
expiration, I'd say write-through. When updating status, I'd say<br>
cache-only. For permanent contacts, it would always be cache-only.<br>
</blockquote>
<br>
So - stepping back and implementation details aside. What do we need? In an ideal world how would the implementation work?<span><font color="#888888"><br>
<br></font></span></blockquote><div><br></div><div>Fair question.</div><div><br></div><div><div>I want to CUD objects and decide whether the results of the operation should be temporary or persistent at the time I perform the operation. I don't want to have to create my own wizard some other specific implementation each time I need this capability.</div><div><br></div></div><div>I want to dynamically create an object and not have to worry that the underlying wizard was res_sorcery_config and therefore doesn't support create.</div><div><br></div><div>I want to update an object and call ast_sorcery_update without having to clone it. It's my job to assess locking requirements. It's sorcery's job to determine whether the object needs to be cloned. A "get_for_update" might help there. It could either lock it before giving it to you or clone it before giving it to you.</div><div><br></div><div>I think that sums it up.</div><div><br></div><div> </div></div></div></div>