Re: How to get user name from 'author' id

In message <[email protected]>,
Ralf Schlatterbeck writes:

>On Wed, Sep 05, 2012 at 10:24:26AM -0400, John P. Rouillard wrote:
>> 
>> I have a patch pending:
>> 
>>   http://issues.roundup-tracker.org/issue2550749
>> 
>> that slightly changes xml handling. Currently if the input mime type
>> is text/xml, it invokes the xmlrpc handler. However REST and other
>> mechanisms can also use xml style data (although json is probably more
>> likely). My patch invokes the xmlrpc hander only when addressed as:
>> 
>>    <roundup_url>/xmlrpc
>> 
>> Would you be able to apply the patch attached to the issue and verify
>> that things still work as expected? I tested it with the examples I
>> could find but didn't really try it in a real world scenario.
>> 
>> For the other roundup developers do we have a feeling for how
>> disruptive this patch would be? Any idea how many people are using the
>> xlmrpc mechanism? Other than more extensive testing, what should
>> happen before this patch is integrated into a release?
>
>I'm regularly using xmlrpc and know of at least one customer using
>it extensively. Your patch should update the documentation on xmlrpc

It does. there is a second patch for the docs on that ticket.

>and the release notes (upgrading.txt) should mention that existing
>xmlrpc scripts will have to be changed.

Ok, I can add a blurb for that.

>Are you planning to implement a REST API or why do you want to change
>this? (this is no opposition, just curiosity)

Well the selection mechanism just seems wrong. If the xmlrpc interface
was selected only for data of type: "text/roundup-xmlrpc", I would be
ok with it. Kind of kludgy to have the data type specify how it should
be consumed but the data type is specific enough that it makes sense.

But "text/xml" really describes the format of the data and not what
application should process it. When I was writing up the rest
interface ticket:

  http://issues.roundup-tracker.org/issue2550734

I realized that I couldn't use it with text/xml input data format
since text/xml would force it to be consumed by the xmlrpc interface
regardless of the url I specified.  IIUC the service (xmlrpc
interface) should be explicitly named in the URI and not intuited from
the type of input data, especially a generic data format such as
text/xml.

As far as REST implementation, I did have a person who was interested
in doing some work on it, but got waylayed by life 8-). I would like
to do some work on it as well as I think it would be a valuable
addition.

But first I need to get my other patches in the mainline and get some
major cycles to dig into the internals of the database layer to figure
out why I am getting messed up data on:

  http://issues.roundup-tracker.org/issue2550731

which apparently has been spammed with attachements. Sigh.

Ralf, any idea on how should I handle the attachment spam? If I just
delete/unlink the file from the ticket the data/link is still
accessible from the history.

Hmm, here is another idea: Should we be annotating links in the
history as:

 <a rel="nofollow" href="..."> ...</a>

so deleted files aren't indexed by google etc.

--
				-- rouilj
John Rouillard
===========================================================================
My employers don't acknowledge my existence much less my opinions.

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/