[Adium-devl] Status event wackiness

[Augie Fackler]

On Jun 8, 2006, at 3:21 PM, Evan Schoenberg wrote:

> Well, you're using the AIContentStatus's sending in order to log  
> the event... I'm pretty sure that's not the right level of  
> granularity.  That's a content object, posted for display to a  
> message view in response to a particular status notification... but  
> part of the fun of XML is recording things in a lossless way. We  
> don't want to record the message "Evan went away" or "Evan is not  
> idle" -- what we want to log, as I see it anyways, is the fact that  
> AIM.tekjew had a status event of CONTACT_STATUS_AWAY_YES or  
> CONTACT_STATUS_IDLE_YES. No?  I think our "internal notification  
> system sucks" because you're not using the right part of it.

What is the right part then? I was poking around with him on this  
last night, and that's the only status notification area I see. As  
far as I can tell the chat window pulls states from the meta change  
just the same as the logging system does, that's where I got the idea  
for the hacktastic workaround. Can someone more familiar with the  
chat window get me an idea on how that system works if it doesn't  
just divine what it needs from the meta status changes?

> That said, the current system is perhaps not quite geared for what  
> you want in that it automagically consolidates status changes to  
> make sense at a metacontact level. CONTACT_STATUS_AWAY_YES is not  
> going to be posted if you have me on AIM and MSN, I'm already away  
> on MSN, and I go away on AIM.  Everything about the notification  
> system... at present anyways... says that's redundant information  
> -- no growl notification, no sound, etc.  In the general case, I  
> think this is what should be... because generally people on with  
> multiple services or names go away or idle on all of them at once,  
> and we wouldn't want to display a string of notifications all  
> related to the metacontact Colin, each of which was referring to a  
> different name/service. Thoughts?

The current system is geared for CL updates, which means that meta  
notifs get combined before they are actually posted. Growl/CL et al  
only care about the overall state of a meta, rather than the meta's  
individual contents. In a sense, the current system is correct for  
everything not logging. Nifty, isn't it?

>
> -Evan


This message brought to you by The Beatles and the number epsilon_0

Augie


>
> On Jun 8, 2006, at 12:21 AM, Colin Barrett wrote:
>
>> Recently, while working on XML logging, I ran into a really lame
>> issue/bug. Here's the relevant work around for XML logging, and a
>> ticket which describes some wackiness in the message view which I
>> believe to be related.
>>
>> http://trac.adiumx.com/changeset/16183 and http://trac.adiumx.com/
>> ticket/4226
>>
>> To summarize, I'm of the opinion that our internal notification
>> system sucks. A lot. Going forward, it's going to make implementing
>> logging, especially the <event> tag, a pain in the ass. What should
>> we do, if anything, to improve it? Augie suggested a central
>> NotificationCenter for listObject status notifications. I think it
>> would be nice to have categories of events. You could subscribe to
>> that entire category and get all of the notifications in that  
>> category.
>>
>> What do you guys think?
>>
>> -Colin
>>
>> _______________________________________________
>> Adium-devl mailing list
>> Adium-devl at adiumx.com
>> http://adiumx.com/mailman/listinfo/adium-devl_adiumx.com
>>
>
> _______________________________________________
> Adium-devl mailing list
> Adium-devl at adiumx.com
> http://adiumx.com/mailman/listinfo/adium-devl_adiumx.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
URL: <http://adium.im/pipermail/devel_adium.im/attachments/20060608/9b76f3ce/attachment.sig>