[Pidgin] #12519: Patch for "pounce when my status is..."

[Pidgin]

#12519: Patch for "pounce when my status is..."
--------------------------------------------+-------------------------------
 Reporter:  grigoryj                        |        Owner:  darkrain42
     Type:  patch                           |       Status:  new       
Milestone:  Patches Needing Improvement     |    Component:  libpurple 
  Version:  2.7.3                           |   Resolution:            
 Keywords:  pidgin libpurple pounce status  |  
--------------------------------------------+-------------------------------

Comment(by grigoryj):

 Replying to [comment:9 darkrain42]:
 > Before I go any further, let me just say that date format is absolutely
 horrid.  Either use something exactly like the format in
 [http://xmpp.org/extensions/xep-0082.html XEP-0082: XMPP Date and Time
 Profiles] or a UTC unix timestamp :)
 Thanks, I'll take this into accout when writing that patch.

 >
 > The parsing there is already overly cumbersome -- it needs to be
 rewritten to use the xmlnode parser like all the other subsystems do.

 Well, that's not an excuse for making it even more ugly, is it?

 > I'm still not entirely sure I understand what the current pounces parser
 is doing (or that your changes so far are correct!).  So keep that in mind
 when designing a schema.  In any event "fields" doesn't really describe
 something about what it's going to contain (in this case you seem to be
 aiming toward including filters/selectors on the event).  Statuses should
 be all grouped together (look at accounts.xml), but not with things that
 aren't semantically similar.

 Well, we can group the statuses together without changing the format
 significantly (if I correctly understood what you mean, of course):
 {{{
 <fields>
  <field name="statuses" value="away,invisible"/>
 </fields>
 }}}

 Again, adding new structural elements means even more ugly XML-parsing
 code. Plus, having a separate xml tag for each field type... well, just
 doesn't feel right. However, maybe "hierarchical" field structure is a way
 to go:
 {{{
 <fields>
  <field name="statuses">
   <field name="status" value="away"/>
   <field name="status" value="invisible"/>
  </field>
 </fields>
 }}}
 This is a neat idea, IMO because it allows a more "uniform" parsing code.

-- 
Ticket URL: <http://developer.pidgin.im/ticket/12519#comment:10>
Pidgin <http://pidgin.im>
Pidgin