On 30 May 2013, at 18:21, Antonia Horincar <[email protected]> wrote:
> On Thu, May 30, 2013 at 4:25 AM, Olemis Lang <[email protected]> wrote: >> On 5/29/13, Antonia Horincar <[email protected]> wrote: >>> Hi, >> >> :) >> >>> On Tue, May 28, 2013 at 9:54 PM, Olemis Lang <[email protected]> wrote: >> [...] >>>> >>>> Yes , during the last few days I've been thinking of ways to improve >>>> RestOnTrac plugin and I'm working now (and will be suring the next few >>>> days) towards version 2 of the API . This means you'll get these >>>> answers asap , and I'll be accepting both feedback and patches based >>>> on your work . >>>> >>>> What will be your starting point ? ... so that I can manage priorities >>>> ... >>> >>> Thank you for your reply. Since I still don't know very much about >>> RestOnTrac's structure, I can't tell for sure what will be my starting >>> point for the back-end part. >> >> I meant to ask this : Will you start with embedding ticket data in >> external sites ? or maybe some other data hosted by Bloodhound ? ... >> which one ? > > Well, I can start with any of them. Do some of the objects have > priority over some other ones? (e.g. tickets over versions?) I think this is a reasonable order of priority: Ticket > Milestone > Version > Product > Component > Source > Everything else Which part you prefer to tackle first is up to you. > >> reports >>> This is why I would appreciate some >>> explanation on the plugin's internal structure. >> >> I'll provide these asap . Nevertheless in a few words , API v2 will be >> very similar to django-piston i.e. a Resource class with methods for >> CRUD operations , and routes definitions in the fornt-end > > Great, thanks a lot! > >> >> >>>> PS: I've also been thinking of many other nice improvements too ... in >>>> the fridge ... >>>> ;) >> [...] >>> >>> Also, I want to share what Shiva Teja (also a member of this mailing >>> list) suggested to me yesterday. He wanted to share with me his idea >>> on implementing the back-end of the project, which implied using >>> IRequestHandler >> >> The RestModule class already implements IRequest handler to process >> HTTP requests ... >> >>> for dealing with web requests and the TracTicketSystem >>> class to get the content of a specific ticket. >> >> ... and (will) provide wrappers and helpers to reuse (tested) >> BloodhoundRPC handlers retrieving data hosted by the environment (i.e. >> not just tickets), assert permissions , pluggable API authentication >> methods , etc ... >> >>> Can anyone give some >>> feedback on this, as I want to make a comparison between this approach >>> and the one involving RestOnTrac, and choose the best one? >> >> You could do everything from scratch , or reuse REST and/or RPC >> backend . I'll prioritize working and testing ticket REST endpoint of >> the API and come back to you with further details . > > I guess I will use the existing implementation of IRequestHandler for > processing HTTP requests, it wouldn't make sense to implement it from > scratch... > >> From the perspective of API consumers you'll retrieve the (XML | JSON >> | YAML | ...) representation of ticket 123 by issuing an HTTP GET >> request to /api/ticket/123 >> >> [...] >> >> -- >> Regards, >> >> Olemis. > > Thanks, > Antonia
