On Wed, Sep 10, 2014 at 12:38 PM, Stephan Beal <sgb...@googlemail.com> wrote:
> In principal, plain old transport is not the problem. The problem (as i > recall it, though it's been a while and i've got the memory of a goldfish) > was that i could not define a concrete structure for JSON/Ticket I/O > because tickets are customizable. Suggestions are of course welcomed, and > if there's a concrete case you or Eric have in mind, i can probably say > whether it's currently workable or estimate what it would take to make it > so. > Is it not possible to define an open-ended list of name-value pairs? More off-hand thinking: A new ticket from Jira (or other) would just be a "new ticket" request with accompanying field data, including the Jira ID. An update from Jira, I assume the intermediary would need to query Fossil based on the Jira ID, then use the returned Fossil ticket ID to send the updated field data. For updates from Fossil, would need to devise a way to discover the updated tickets (maybe the intermediary keeps track of when it gets updates then queries for tickets changes newer than the time stamp.)
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
