[Mulgara-dev] ITQL

[Alex Hall]

Paul Gearon wrote:
> On Sat, Jul 12, 2008 at 3:03 PM, Life is hard, and then you die
> <ronald at innovation.ch> wrote:
>> It's basically fine, except: why "client"? To me, the parsing should
>> be on the server, and the client lib should be sending over tql or
>> sparql strings.
>>
>> Also, if I were coming to this project new, I'd expect to find a nice
>> client lib in org.mulgara.client :-) (we've discussed this before)
>>
>> So, dunno, but maybe something like org.mulgara.parsers instead?
> 
> Nope, because this section is not just about parsing. It's also about
> responses back to the client.
> 
> You're right though. I was thinking "client" because under rmi all of
> that work IS on the client. But I want rmi to become an infrequently
> used option, and not the standard paradigm, so I should have stopped
> thinking on those terms some time ago.

Perhaps think of it as "client" in the sense of a client of the 
Connection (or Session) interface.  Sessions and Connections accept 
Queries, so something always has to parse a TQL or SPARQL string into a 
Query to pass off to the database.  It could be the client explicitly 
parsing the query, or it could be a proxy for the client running on the 
server.  But the interface to the database itself is the Session 
interface, so regardless of whether the transport is RMI or another 
mechanism, the parsing is done by a client.

> So what name should I be thinking of if it's not client code, but it's
> specifically about talking to clients?

We already have that package: org.mulgara.query.  So how about 
org.mulgara.query.lang?

Alex