[Citadel Development] Re: Citadel commit log: revision 8546
So there wasn't a Delete operation at the time I started writing this? Oops :) At the moment, the key and value are both the full address. If you want to change it to a hash later, that's fine, but please let me finish the application logic first.
[Citadel Development] Re: Citadel commit log: revision 8546
2. Delete (from the hash table) any buddies who happen to be online *now* Heh, Perfect! we just implemented Deleting ;-) Maybe we need to do this with a Hashkey now too.
[Citadel Development] Re: Citadel commit log: revision 8546
Let's not mess with it yet -- the module is not finished. The reason I'm maintaining this "xmpp mortuary" is because when a Jabber client logs in, the first thing we have to do is flush out all of the roster entries that existed in all previous sessions. Stupidly, XMPP doesn't have a way to tell the client to do this. So we have to "remember" all possible buddies that the client *might* have in its roster, and delete them So, what I still need to have it do at the beginning of a session is: 1. Load the mortuary 2. Delete (from the hash table) any buddies who happen to be online *now* 3. Send roster-delete messages for all the others And yes, the list will grow forever. There's no way to avoid it.
[Citadel Development] Re: Citadel commit log: revision 8546
Fr Apr 30 2010 09:43:39 EDT von IGnatius T Foobar @ Uncensored Betreff: Re: Citadel commit log: revision 8546 probably just because i'm used to memcpy; I thing strndup will check for \0 while copying which we don't need to since we know the length? We're going to continue to have a difference of opinion on this. I still prefer readability and maintainability over shaving off a handful of cpu cycles. well, Readability is also a thing depending on what you're used to ;-P I'd be in for doing this with StrBuf so you're shure its fast, correct (no buffer cuts etc.), and readable.
[Citadel Development] Re: Citadel commit log: revision 8546
>probably just because i'm used to memcpy; I thing strndup will check >for \0 while copying which we don't need to since we know the length? We're going to continue to have a difference of opinion on this. I still prefer readability and maintainability over shaving off a handful of cpu cycles.
[Citadel Development] Re: Citadel commit log: revision 8546
Ok, I see that. When you call Put() you're transferring control of the memory to the hash table; it doesn't copy it over. But why did you fix it the long way instead of just calling strdup() ?
[Citadel Development] Re: Citadel commit log: revision 8546
Ah, you found my bug and fixed it already? Thanks!