On Thu, Apr 30, 2015 at 3:03 PM, Joshua Colp <[email protected]> wrote:
> George Joseph wrote: > >> >> >> On Thu, Apr 30, 2015 at 2:01 PM, Joshua Colp <[email protected] >> <mailto:[email protected]>> wrote: >> >> George Joseph wrote: >> >> >> <snip> > >> What if contacts are stored in an external database? Your proposal >> would also have them going there as well. This would require an >> explanation for deployers to know what is going on exactly and what >> they are. As well this means there would be a period of time where >> the permanent contacts would not be present if other instances are >> sharing the same database and one restarts. >> >> >> They can't be today can they? The dynamic ones are explicitly mapped to >> astdb and the permanent ones are explicitly placed in the aor based >> container. Can you even use sorcery.conf to map contacts somewhere else >> given that they're just strings in an aor? >> > > You sure can. > > Who would even know they can do that besides you? :) > <snip> > > >> A contact is updated when the registration is refreshed, you have to >> persist that out to disk or if a restart occurs it'll be expired. >> >> >> Yes, so for dynamic contacts, the expiration would be written with the >> normal update and for status and rtt changes, with update_temp. >> > > 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. > 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. > > >> >> For permanent contacts, we do the same except we call >> ast_sorcery_create_temp and ast_sorcery_delete_temp so they >> never get >> persisted to astdb. >> >> >> So. This is what I was originally trying to express when you did the >> wizard work, you've just gone about it in a different manner. I >> think this is a rather specialized addition that could be done in a >> better way. >> >> Right now sorcery wizards can't be programmatically added. They just >> can't. You have to do it from the sorcery.conf configuration file. >> >> >> Not true. ast_sorcery_apply_wizard_mapping allows yo to add a wizard to >> any object type at run time. That's what the config_wizard does. When >> the object type registers, it adds a memory wizard to the object type's >> wizard list. The config wizard then manipulates the memory wizard. >> > > 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. > You don't need a handle, you have the wizard itself. Correct on the order. > >> >> What if they could be? >> What if you could add a wizard that's marked as caching (so it's >> only queried) but still have a handle to it to create/update/destroy? >> >> >> You just described res_pjsip_config_wizard exactly. >> > > Yes, except without having a direct handle and more control over things > you had to do it in an indirect manner. > > >> >> Wrap that up in a higher level API like you want above and you >> extend sorcery in a way that's useful in multiple ways. >> >> >> Put the whole mutability thing aside for a minute. I guess what I'm >> suggesting that the default sorcery behavior could be an automatic >> read/write cache in front of every sorcery wizard. You can then control >> whether how writes are handled (if at all) by options you give when you >> register the object type, and options you give on CRUD calls. >> > > 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. > 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. > > >> For my contact scenario, I'd say writable cache and a writable back end >> (astdb by default). When writing a new dynamic contact or updating the >> expiration, I'd say write-through. When updating status, I'd say >> cache-only. For permanent contacts, it would always be cache-only. >> > > So - stepping back and implementation details aside. What do we need? In > an ideal world how would the implementation work? > > Fair question. 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. 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. 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. I think that sums it up.
-- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
