[Mulgara-dev] Emailing: protocolServlet POST answercleanup.patch

David Smith DMS at viewpointusa.com
Wed Jan 20 04:27:24 UTC 2010


Much better.
The system is running at least enough to continue testing
Stay tuned.

Dave S

-----Original Message-----
From: mulgara-dev-bounces at mulgara.org [mailto:mulgara-dev-bounces at mulgara.org] On Behalf Of Paul Gearon
Sent: Tuesday, January 19, 2010 8:20 PM
To: Mulgara Developers
Subject: Re: [Mulgara-dev] Emailing: protocolServlet POST answercleanup.patch

On Tue, Jan 19, 2010 at 7:58 PM, David Smith <DMS at viewpointusa.com> wrote:
> Got, will try it out.
> I still think that the protocolServlet handleUpdateQuery() needs some
> attention.
> It currently only renders the last real answer encountered.
> Any others need to be closed properly (again even with subqueries)

Yes, you're right.

I actually did it as a companion to the SPARQL endpoint, so I was
thinking in terms of SPARQL the whole time. SPARQL doesn't have
sub-answers, and it doesn't have multiple queries in a single request,
so I didn't give adequate thought to either of those situations in
TQL.

Incidentally, SPARQL Update *does* accept multiple operations in a
single request. So I need to make sure this part of the servlet is
working by the time I get SPARQL Update implemented!

> OR implement the render multiple answers into one return result  :)

I absolutely think I need to do it this way. Unfortunately, I'll need
to change the interfaces to the output streaming classes to handle
multiple Answers, but I'm sure that will be fine.

> I looked at that briefly, wouldn't be too bad,
> Separate the docheader into pieces, add idea of list of answers --
> change the single answer funcs to convert to a 1 element list,
> and then get emit/generate to understand the list,

Yup, exactly the approach I was considering. I've been spending a lot
of time in Scala recently (to run the SPARQL test suite against
Mulgara), so thinking in terms of lists is coming quite naturally at
the moment.  :-)

> but should be implemented on all streamed answer classes and I'm not
> sure I know what each should do.

Don't worry... I do.  :-) It's a nice, easy looking task. Just the
kind of thing I can do to avoid work (but it will be tomorrow, rather
than tonight, sorry. I'm tired).

> Might be enough to just handle the last Answer in the classes that don't
> want/understand more.

Only TQL needs this special treatment, though the general interfaces
will need to accept lists (the SPARQL versions will need to check that
the list is a singleton). TQL is the only REST interface that can
return more than one query result, and is the only REST interface that
can return sub-answers. SPARQL answers are being covered pretty well.

> Thanks for your help.
>
> I'll let you know how it works out.

I'll see you in the morning.

Regards,
Paul Gearon
_______________________________________________
Mulgara-dev mailing list
Mulgara-dev at mulgara.org
http://mulgara.org/mailman/listinfo/mulgara-dev

This E-Mail may contain confidential and privileged information. It is intended solely for the recipient(s) indicated. Any review, use, or distribution by anyone other than the intended recipient(s) is strictly prohibited. If you have received this E-Mail in error or are not the intended recipient, please notify the sender and delete all copies immediately.



More information about the Mulgara-dev mailing list