On Tue, Feb 28, 2012 at 11:34 PM, Nolan Darilek <[email protected]>wrote:
> On 02/28/2012 03:36 PM, Stephan Beal wrote: > >> Amen. Maybe the JSON API should just support a dumbed-down tags interface? >> >> >> So it seems like the command line/web interface would have to use a > similar tag filter function, right? I mean, they're filtering out these > various tkt/wiki-/event- tags, and presumably others besides. Maybe if > everything followed the same code path, we'd be golden? The presumption of the same code paths is fair but unfortunately not the case. The various CLI-vs-HTML-vs-JSON forms of various commands share ashamingly little code. The command-specific logic and ad-hoc data structures (in the form of queries) are normally quite interwoven together. When i started the JSON API it quickly became apparent that it would be too unwieldy and intrusive to interweave the JSON API's logic with the existing HTML/CLI modes, and ended up copying more than a small number of queries from the main implementations. In some cases it has been possible/feasible to factor out shared code for certain routines, but in many cases that hasn't been feasible. (This split/code dupe helps ensure, however, that HTML/CLI/JSON interfaces can evolve independently of each other.) Then all other interfaces be they command line or JSON could require that > you opt into whatever other tag types you'd like. The current JSON impl is based on the parameters available to the HTML interface, though often renamed to something more JSON-conventional. i like what Ron suggests: On Wed, Feb 29, 2012 at 12:33 AM, Ron Wilson <[email protected]> wrote: > On Tue, Feb 28, 2012 at 5:34 PM, Nolan Darilek <[email protected]> > wrote: > > followed the same code path, we'd be golden? Then all other interfaces be > > they command line or JSON could require that you opt into whatever other > tag > > types you'd like. > > This makes a lot of sense. Not automatically give everything, but do > allow asking for more. And i'll certainly give that consideration. i'm all ears if you guys have concrete ideas on how the interface should look like. For simplicity, just model your ideas like CLI args (these tend to map easily to HTTP-mode equivalents), e.g.: fossil json tag list -t -w ... -t = include tickets -w = include wiki Should there be a separate command for fetching full key/value pairs (which changes the response structure), or should that simply be an option of the 'list' command (e.g. --verbose)? What should happen if no options are provided - what tags are returned in such a case (or is it an error)? i don't personally use tags all that much, so i could really use suggestions from those who make have use of (or can envision interesting use cases for) tags. :-? -- ----- stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal
_______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
