Quantcast

[RFC/PATCH 0/3] JSON/XML output for scripting interface

classic Classic list List threaded Threaded
24 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [RFC/PATCH 0/3] JSON/XML output for scripting interface

Jon Seymour
I can see that retrofitting this more widely would add quite a lot of
conditional logic to a lot of places.

If one was designing for both line-oriented and structured outputs
from the start, I imagine one would build a map for each record, and
then hand that to the output context when it is complete, allowing the
considerations of both line orientation and structured output to be
encapsulated within the backend. Self-describing output formats can
use a simple map without needing to know the record type, but line
oriented outputs, of course, would need to know the type of record in
order to select the correct line formatter.

So, would it be worth providing a hint as to record type in the
output_start_object call so that if it was later desired to subsume
line-oriented formats under the same framework, there is enough
information available to the backend to do that?

[ And, yes, I understand that to making line-oriented formats a
backend would be a reasonably invasive change to existing code that
would involve a level of indirection and abstraction that may not be
to everyone's taste. ]

jon.

On Mon, Apr 12, 2010 at 3:50 AM, Sverre Rabbelier <[hidden email]> wrote:

> Heya,
>
> On Sun, Apr 11, 2010 at 19:45, Julian Phillips <[hidden email]> wrote:
>> I think that there probably are commands where it will be more work to
>> integrate the output - but I think that is probably more to do with the
>> structure of the current code than the API of the new.  Does it make a
>> difference what the API of the new output code is if there isn't currently
>> a sensible hook-in point?
>
> No you are right, the existance of such hard-to-change commands does
> not really affect the API design in this case, although I think it
> might be a good idea to try out at least one such command before
> committing to using this API. For example, it might turn out that
> there's an elegant way to hook in, or that adding all those if
> (output_style != OUTPUT_NORMAL)  statements gets cluttery and there
> should be a different way to do things instead.
>
>> If code has been written without the expectation that the output format
>> could be changed then the effort to add a new output format could be
>> considerably more than for status or ls-tree.  However, with the
>> frontend/backend design hopefully we only have to endure the effort once to
>> get multiple output formats.
>
> I'm curious to see where this will lead us :).
>
> --
> Cheers,
>
> Sverre Rabbelier
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to [hidden email]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [RFC/PATCH 0/3] JSON/XML output for scripting interface

Eric S. Raymond
Jon Seymour <[hidden email]>:
> [ And, yes, I understand that to making line-oriented formats a
> backend would be a reasonably invasive change to existing code that
> would involve a level of indirection and abstraction that may not be
> to everyone's taste. ]

For whatever my opinion is worth I think this is a good direction to
go in.  I think it fits the well-established git design philosophy of
separating content manipulation (plumbing) from presentation
(porcelain).
--
                <a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [RFC/PATCH 0/3] JSON/XML output for scripting interface

Jon Seymour
In reply to this post by Jon Seymour


On 12/04/2010, at 8:22, Jon Seymour <[hidden email]> wrote:
>
> So, would it be worth providing a hint as to record type in the
> output_start_object call so that if it was later desired to subsume
> line-oriented formats under the same framework, there is enough
> information available to the backend to do that?

Of course, one way to do this would be to use a more descriptive  
record name than "entry". This would make the record itself (as  
opposed to just it's fields) self-describing.

The point is, you would want to start using descriptive record names  
now so that you don't end up locked into a partially context sensitive  
base of consumers who are expecting their JSON records to be called  
"entry" and using context hints to infer the actual record type.

jon.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [RFC/PATCH 0/3] JSON/XML output for scripting interface

Julian Phillips
On Mon, 12 Apr 2010 09:25:04 +1000, Jon Seymour <[hidden email]>
wrote:

> On 12/04/2010, at 8:22, Jon Seymour <[hidden email]> wrote:
>>
>> So, would it be worth providing a hint as to record type in the
>> output_start_object call so that if it was later desired to subsume
>> line-oriented formats under the same framework, there is enough
>> information available to the backend to do that?
>
> Of course, one way to do this would be to use a more descriptive  
> record name than "entry". This would make the record itself (as  
> opposed to just it's fields) self-describing.
>
> The point is, you would want to start using descriptive record names  
> now so that you don't end up locked into a partially context sensitive  
> base of consumers who are expecting their JSON records to be called  
> "entry" and using context hints to infer the actual record type.

I have to admit that most of the names were just "first idea out of the
hat" - not really something I was paying too much attention to.  It's
fairly easy to tweak them later, provided it's done before they get
published.

Having said that, I've just mailed out v2 patches, which already include
line-based output (using a different approach). ;)

More descriptive names are probably something that should be done anyway
though.

--
Julian
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
12
Loading...