On Thu, Apr 30, 2015 at 4:45 PM, George Joseph <[email protected]> wrote:
> > > On Thu, Apr 30, 2015 at 3:59 PM, Joshua Colp <[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? :) >>> >> >> I believe there's a wiki page which details using PJSIP with realtime, >> and there's also the table in alembic. >> >> > In general there is. There aren't any specific instructions for contacts > though. Permanent contacts specifically. The ERD on the wiki shows contact > but pjsip.conf.sample only mentions contacts in the context of aors. > There's no object mentioned. If we took a poll, how many people would > respond that they know they could define permanent contacts in realtime as > separate objects. :) > > > >> <snip> >> >> 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. >>> >> >> How? What I'm talking about is something like: >> > > You can get the wizard as a result of the wizard_mapped observer. > > >> >> int res; >> struct ast_sorcery_wizard *wizard; >> void *data; >> res = ast_sorcery_apply_explicit_wizard(sorcery, "endpoint", "memory", >> "", &wizard, &data); >> >> That function would explicit at a wizard to the front, and return the >> specific wizard interface and instance. Instant access to manipulate that >> specific instance with the CRUD interface and a guarantee of its position. >> >> > Agreed and that's easy enough. I'm not sure it helps any though. > > >> >>> >>> >>> >>> 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. >>> >> >> No, I don't, but I also don't want the lower level sorcery core to become >> even more complex and have additional burden. Thin, simple (as much as >> possible), to the point. If higher level APIs exist which build on it to >> provide the functionality then I'm all for it. >> >> >>> >>> >>> 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. >>> >> >> This is even lower level then I was thinking of. Within the scope of >> contacts and contact status - what would be the best way for them to work? >> >> "When a contact status changes I need to be able to store this >> information" >> > > From who's perspective though? > > When any contact is added, updated or deleted, I want the same observer to > be called. I don't want to have to code differently for permanent contacts > vs dynamic contacts. > > I want to create a temporary contact that sticks around until I delete it > or Asterisk restarts. > > I want to update a contact's status/rtt and indicate that the change > should be discarded when Asterisk restarts. > > I want to update expiration and indicate that the change should be > permanent. > > I don't want to care which wizards support CUD and which don't. > > > Oh yeah. I don't want a user to have to screw around with sorcery.conf to get basic behavior.
-- _____________________________________________________________________ -- 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
