the search api?

[Dean Landolt <de...@deanlandolt.com>]

Paul Davis' work on integrating couch and
xapian<http://code.google.com/p/couchprojects/source/browse/trunk/query_servers/xapian/README?r=23>seems
like a good jumping-off point. But it seems to me it would be great if
I could do something like this with an abstraction layer between couch and
the search software (as an added bonus the code wouldn't have to be GPL'd
and could be distributed with couch). From what I can tell
pyndexter<http://swapoff.org/wiki/pyndexter/docs>looks like a nice
option -- it's got a great API and even has its own
built-in engine (pure-python, so slow, but no additional deps). Plus
pluggable multilingual stemming and a nice query syntax, etc...

I'm going to see if I can't turn this into a generic middleware layer that
can catch couch's updates on stdin to update the index, but I don't even
know where to begin in connecting the query server. From what I gather,
there's no longer a /db/_search api -- how are these calls supposed to be
invoked? Any information would be fantastic. Couch has proved everything
I've wanted and more -- but I'd kill for a servicable search option...

Dean

Re: the search api?

[Dean Landolt <de...@deanlandolt.com>]

> And because Dean mentioned mental masturbation, I feel that it's my
> duty to link to Linus Torvalds' latest headline making email:
> http://article.gmane.org/gmane.linux.kernel/706950


Ha! Always good for a laugh, that crazy kid. I honestly would have been
inclined to agree with him until about a few months ago when I learned how
ridiculously easy it was to exploit that Debian entropy
bug<http://www.metasploit.com/users/hdm/tools/debian-openssl/>
!

Re: the search api?

[Paul Davis <pa...@gmail.com>]

Couples posts all at once, I chose to respond to this one strictly
because it included the phrase mental masturbation.

For Chris's not about the stdio json protocol, there's a patch on one
of the jira issues to make this more standardized. Specifically I
think to match the view server output. Not sure if the one blank line
vs. two is the same, but that should be easy (and is a good idea). I
think the important question though is if this is how things are going
to stay. And there are other fine details, but nothing that should
stand in the way of us hacking something together for the time being.

As to Noah's email, well, I really have no idea. If it turns out that
using GPLv3 is fine, then so be it. Otherwise, if we have to use
something else to get "out-of-the-box-search" then so be it.

And because Dean mentioned mental masturbation, I feel that it's my
duty to link to Linus Torvalds' latest headline making email:
http://article.gmane.org/gmane.linux.kernel/706950

Paul

On Fri, Jul 18, 2008 at 10:35 AM, Dean Landolt <de...@deanlandolt.com> wrote:
> On Fri, Jul 18, 2008 at 9:14 AM, Paul Davis <pa...@gmail.com>
> wrote:
>
>> Noah,
>>
>> See, that's the kicker. I don't by any means want to distribute the
>> bindings. But by virtue of the GPL, if you're code uses, say for
>> instance, the Xapian bindings you're code must be released under the
>> GPL. Ie, by mere virtue of having "import xapian" in your python
>> script it would have to be released under the GPL.
>
>
> I'm no IP expert (though I do waste exhorbenant amounts of time studying
> it), but I don't believe that's what puts you on the hook for
> *distribution*(the key phrase to the spell of the GPL). You're not
> responsible for how the
> *xapian* egg got into site-packages, and even if you were (say you had it as
> a requirement in your setup.py script), you're still not distributing. Only
> if you include the package that links to the xapian binary as part of your
> distribution would you be on the hook.
>
> It wasn't until I put that one together that I realized how much I
>> dislike the GPL.
>
>
> It's not all bad. But yeah, I'd been on the fence for about this for a
> while, but I'm starting to feel the same way.
>
> As to the erlang FTI idea, I'd be all for this too. Keeping as much in
>> erlang as possible seems like a good idea to me. It just so happens
>> that one of the short examples in Programming Erlang is about creating
>> such a beast. Granted its small and trivial, but its a place to start
>> from.
>
>
> Small and trivial's all I'd even want (the simple FTI implementation in
> pyndexter is what turned me on to it -- it was easy to just get started with
> and see results). But still, the lack of a dead-simple api in couch makes
> toying around with it nothing more than mental masturbation for now. Which
> is fine by me.
>
>
>> Now, if anyone wants to go and implement a decent stemmer and
>> all the other whizbang features that people expect from a FTI, I'd
>> probably jump on board with that.
>
>
> Luckily stemming (in English at least) is just about picking a known
> algorithm (and implementing, presumably). That would be a great exercise for
> learning Erlang -- something I'd be interesting in taking on when I do take
> that leap (not for at least 6 months I'd imagine).
>

Re: the search api?

[Dean Landolt <de...@deanlandolt.com>]

On Fri, Jul 18, 2008 at 9:14 AM, Paul Davis <pa...@gmail.com>
wrote:

> Noah,
>
> See, that's the kicker. I don't by any means want to distribute the
> bindings. But by virtue of the GPL, if you're code uses, say for
> instance, the Xapian bindings you're code must be released under the
> GPL. Ie, by mere virtue of having "import xapian" in your python
> script it would have to be released under the GPL.


I'm no IP expert (though I do waste exhorbenant amounts of time studying
it), but I don't believe that's what puts you on the hook for
*distribution*(the key phrase to the spell of the GPL). You're not
responsible for how the
*xapian* egg got into site-packages, and even if you were (say you had it as
a requirement in your setup.py script), you're still not distributing. Only
if you include the package that links to the xapian binary as part of your
distribution would you be on the hook.

It wasn't until I put that one together that I realized how much I
> dislike the GPL.


It's not all bad. But yeah, I'd been on the fence for about this for a
while, but I'm starting to feel the same way.

As to the erlang FTI idea, I'd be all for this too. Keeping as much in
> erlang as possible seems like a good idea to me. It just so happens
> that one of the short examples in Programming Erlang is about creating
> such a beast. Granted its small and trivial, but its a place to start
> from.


Small and trivial's all I'd even want (the simple FTI implementation in
pyndexter is what turned me on to it -- it was easy to just get started with
and see results). But still, the lack of a dead-simple api in couch makes
toying around with it nothing more than mental masturbation for now. Which
is fine by me.


> Now, if anyone wants to go and implement a decent stemmer and
> all the other whizbang features that people expect from a FTI, I'd
> probably jump on board with that.


Luckily stemming (in English at least) is just about picking a known
algorithm (and implementing, presumably). That would be a great exercise for
learning Erlang -- something I'd be interesting in taking on when I do take
that leap (not for at least 6 months I'd imagine).

Re: the search api?

[Paul Davis <pa...@gmail.com>]

Noah,

Regardless of the outcome, thanks for following up on this. It kinda
sucks that we even have these issues with trying to use multiple open
source projects.

Anyway, we can always look harder at pyndexter or some of the other
projects if we're dead set on including out of the box search
functionality. (Which I would vote for.)

Paul

On Sat, Jul 19, 2008 at 8:20 AM, Noah Slater <ns...@apache.org> wrote:
> On Fri, Jul 18, 2008 at 04:24:54PM +0100, Noah Slater wrote:
>> Okay, I will take this to apache-legal later today when I have time.
>
> Okay, from a thread on legal-discuss:
>
>  * The AL2's "compatibility" with the GPL3 is, annoyingly, a one way affair. As
>   such, you can include AL2 licenced code in a GPL3 project without relicensing
>   but not the other way around.
>
>  * The official ASF policy is that an Apache project MUST NOT depend on any
>   code or library that is GPL licensed (or similar) regardless of the effects
>   this may or may not have on the core code. The reason being that it would
>   effectively enforce users of the Apache project to install and run GPL code.
>
> What a shame, Xapian is pretty cool. From my chats with the developers they
> mentioned that they would like to relicense to LGPL but about 40% of the code is
> owned by some company that had paid for various people to work on the project
> and that they are in the middle of some long and complex effort to rewrite those
> parts. So, I wouldn't hold my breath.
>
> Best,
>
> --
> Noah Slater, http://people.apache.org/~nslater/
>

Re: the search api?

[Noah Slater <ns...@apache.org>]

On Fri, Jul 18, 2008 at 04:24:54PM +0100, Noah Slater wrote:
> Okay, I will take this to apache-legal later today when I have time.

Okay, from a thread on legal-discuss:

 * The AL2's "compatibility" with the GPL3 is, annoyingly, a one way affair. As
   such, you can include AL2 licenced code in a GPL3 project without relicensing
   but not the other way around.

 * The official ASF policy is that an Apache project MUST NOT depend on any
   code or library that is GPL licensed (or similar) regardless of the effects
   this may or may not have on the core code. The reason being that it would
   effectively enforce users of the Apache project to install and run GPL code.

What a shame, Xapian is pretty cool. From my chats with the developers they
mentioned that they would like to relicense to LGPL but about 40% of the code is
owned by some company that had paid for various people to work on the project
and that they are in the middle of some long and complex effort to rewrite those
parts. So, I wouldn't hold my breath.

Best,

-- 
Noah Slater, http://people.apache.org/~nslater/

Re: the search api?

[Noah Slater <ns...@apache.org>]

On Fri, Jul 18, 2008 at 10:49:56AM -0400, Dean Landolt wrote:
> > So the upshot of this seems to be that we can use Xapian, "link" to it and
> > even
> > bundle the source code if we wished.
>
> They're compatible, sure. But the downside is that by tying the packages
> together you'd effectively be subjecting the whole project to the terms of
> the GPL. Making a proprietary fork of the project would be made more
> difficult (a fundamental right of the Apache license). Of course, this
> doesn't matter at all to me as I only deal in free software, but it
> complicates things a bit. Apparently it scares the heck out of an awful lot
> of suits. I remember how difficult it was for me to convince the Library of
> Congress that they wouldn't have to release all their source code if I
> integrated even an LGPL tool (TinyMCE) into one of their systems. They're
> still not completely convinced. If it were plain GPL, I can't even imagine
> how that would have went.

Okay, I will take this to apache-legal later today when I have time.

Thanks for the feedback guys, I'll keep you all posted.

-- 
Noah Slater, http://people.apache.org/~nslater/

Re: the search api?

[Dean Landolt <de...@deanlandolt.com>]

> So the upshot of this seems to be that we can use Xapian, "link" to it and
> even
> bundle the source code if we wished.


They're compatible, sure. But the downside is that by tying the packages
together you'd effectively be subjecting the whole project to the terms of
the GPL. Making a proprietary fork of the project would be made more
difficult (a fundamental right of the Apache license). Of course, this
doesn't matter at all to me as I only deal in free software, but it
complicates things a bit. Apparently it scares the heck out of an awful lot
of suits. I remember how difficult it was for me to convince the Library of
Congress that they wouldn't have to release all their source code if I
integrated even an LGPL tool (TinyMCE) into one of their systems. They're
still not completely convinced. If it were plain GPL, I can't even imagine
how that would have went.

Re: the search api?

[Noah Slater <ns...@apache.org>]

On Fri, Jul 18, 2008 at 09:14:36AM -0400, Paul Davis wrote:
> See, that's the kicker. I don't by any means want to distribute the
> bindings. But by virtue of the GPL, if you're code uses, say for
> instance, the Xapian bindings you're code must be released under the
> GPL. Ie, by mere virtue of having "import xapian" in your python
> script it would have to be released under the GPL.

I think we can use and distribute Xapian and it's bindings with CouchDB.

I've been chatting with the Xapian developers and here's what came up.

15:26 < richardb> Xapian's source files all say:
15:26 < richardb> This program is free software; you can redistribute it and/or
15:26 < richardb>  * modify it under the terms of the GNU General Public License as
15:26 < richardb>  * published by the Free Software Foundation; either version 2 of the
15:26 < richardb>  * License, or (at your option) any later version.

...

15:27 < richardb> So, you can use it under version 3 if you want - we'll be
                  continuing to distribute it under v2 or later for the forseable future.

Digging a little further:

 The Free Software Foundation considers the Apache License, Version 2.0 to be a
 free software license, compatible with version 3 of the GPL.

  - http://www.apache.org/licenses/GPL-compatibility.html

 Apache License, Version 2.0

    This is a free software license, compatible with version 3 of the
    GPL. Please note that this license is not compatible with GPL version 2,
    because it has some requirements that are not in the older
    version. These include certain patent termination and indemnification
    provisions.

 - http://www.apache.org/foundation/licence-FAQ.html#GPL
 - http://www.fsf.org/licensing/licenses/#SoftwareLicenses

So the upshot of this seems to be that we can use Xapian, "link" to it and even
bundle the source code if we wished.

-- 
Noah Slater, http://people.apache.org/~nslater/

Re: the search api?

[Paul Davis <pa...@gmail.com>]

Noah,

See, that's the kicker. I don't by any means want to distribute the
bindings. But by virtue of the GPL, if you're code uses, say for
instance, the Xapian bindings you're code must be released under the
GPL. Ie, by mere virtue of having "import xapian" in your python
script it would have to be released under the GPL.

It wasn't until I put that one together that I realized how much I
dislike the GPL.

As to the erlang FTI idea, I'd be all for this too. Keeping as much in
erlang as possible seems like a good idea to me. It just so happens
that one of the short examples in Programming Erlang is about creating
such a beast. Granted its small and trivial, but its a place to start
from. Now, if anyone wants to go and implement a decent stemmer and
all the other whizbang features that people expect from a FTI, I'd
probably jump on board with that.

Paul

On Fri, Jul 18, 2008 at 8:42 AM, Noah Slater <ns...@apache.org> wrote:
> On Thu, Jul 17, 2008 at 06:36:14PM -0400, Paul Davis wrote:
>> It depends on what license the bindings are released under. Assuming
>> they're GPL'd like Xapian's then the answer is that we distribute
>> separately. To me that's a slight annoyance. Pyndexter appears to be
>> under a BSDish license judging from the COPYING file. Not that I read
>> it, but it looks like the same format and length.
>
> I see absolutely no reason why we would want to distribute the bindings anyway.
>
> We don't distribute any other bindings or 3rd party libs apart mochiweb, and
> that's only because the project is still quite young.
>
> --
> Noah Slater, http://people.apache.org/~nslater/
>

Re: the search api?

[Noah Slater <ns...@apache.org>]

On Thu, Jul 17, 2008 at 06:36:14PM -0400, Paul Davis wrote:
> It depends on what license the bindings are released under. Assuming
> they're GPL'd like Xapian's then the answer is that we distribute
> separately. To me that's a slight annoyance. Pyndexter appears to be
> under a BSDish license judging from the COPYING file. Not that I read
> it, but it looks like the same format and length.

I see absolutely no reason why we would want to distribute the bindings anyway.

We don't distribute any other bindings or 3rd party libs apart mochiweb, and
that's only because the project is still quite young.

-- 
Noah Slater, http://people.apache.org/~nslater/

Re: the search api?

[Benoit Chesneau <bc...@gmail.com>]

On Fri, Jul 18, 2008 at 9:35 AM, Richard Heycock <rg...@roughage.com.au> wrote:
> Excerpts from paul.joseph.davis's message of Fri Jul 18 08:36:14 +1000 2008:
>> On Thu, Jul 17, 2008 at 6:18 PM, Noah Slater <ns...@apache.org> wrote:
>> > On Thu, Jul 17, 2008 at 05:36:05PM -0400, Dean Landolt wrote:
>> >> Or CLucene (for those of us with a violent distaste for all things Java). I
>> >> just learned about a new FTI option: Hyper Estraier -- also GPL, sadly, but
>> >> according to some benchmarks I stumbled across a good bit faster than both
>> >> Xapian and Lucene. And the GPL issue shouldn't be an issue if we're not
>> >> distributing the bindings (hyperestraier has pure-python bindings in PyPI
>> >> (that pyndexter already uses)).
>> >
>> > Does this not apply to Xapian too?
>> >
>> > What is the problem with the GPL as long as we don't distribute the bindings?
>>
>> It depends on what license the bindings are released under. Assuming
>> they're GPL'd like Xapian's then the answer is that we distribute
>> separately. To me that's a slight annoyance. Pyndexter appears to be
>> under a BSDish license judging from the COPYING file. Not that I read
>> it, but it looks like the same format and length.
>
> It seems that Hyper Estraier is LGPL which means that you will be able to
> distribute it.
>
> rgh
>
>
>> >
>> > --
>> > Noah Slater, http://people.apache.org/~nslater/
>> >
>
> --
> +61 (0) 410 646 369
> [e]:  rgh@neoss.com.au
> [im]: rgh@jabber.org
>
> You're worried criminals will continue to penetrate into cyberspace, and
> I'm worried complexity, poor design and mismanagement will be there to meet
> them - Marcus Ranum
>

I would prefer one stable search api rather than only one external
tool packaged with couchdb. So people can use the tool they want : GPL
or not, with the language they want.

Obviously a full search engine in erlang integrated in couchdb would
be perfect. I don't know if some  already exist ?


- benoît

Re: the search api?

[Richard Heycock <rg...@roughage.com.au>]

Excerpts from paul.joseph.davis's message of Fri Jul 18 08:36:14 +1000 2008:
> On Thu, Jul 17, 2008 at 6:18 PM, Noah Slater <ns...@apache.org> wrote:
> > On Thu, Jul 17, 2008 at 05:36:05PM -0400, Dean Landolt wrote:
> >> Or CLucene (for those of us with a violent distaste for all things Java). I
> >> just learned about a new FTI option: Hyper Estraier -- also GPL, sadly, but
> >> according to some benchmarks I stumbled across a good bit faster than both
> >> Xapian and Lucene. And the GPL issue shouldn't be an issue if we're not
> >> distributing the bindings (hyperestraier has pure-python bindings in PyPI
> >> (that pyndexter already uses)).
> >
> > Does this not apply to Xapian too?
> >
> > What is the problem with the GPL as long as we don't distribute the bindings?
> 
> It depends on what license the bindings are released under. Assuming
> they're GPL'd like Xapian's then the answer is that we distribute
> separately. To me that's a slight annoyance. Pyndexter appears to be
> under a BSDish license judging from the COPYING file. Not that I read
> it, but it looks like the same format and length.

It seems that Hyper Estraier is LGPL which means that you will be able to
distribute it.

rgh


> >
> > --
> > Noah Slater, http://people.apache.org/~nslater/
> >

-- 
+61 (0) 410 646 369
[e]:  rgh@neoss.com.au
[im]: rgh@jabber.org

You're worried criminals will continue to penetrate into cyberspace, and
I'm worried complexity, poor design and mismanagement will be there to meet
them - Marcus Ranum

Re: the search api?

[Paul Davis <pa...@gmail.com>]

On Thu, Jul 17, 2008 at 6:18 PM, Noah Slater <ns...@apache.org> wrote:
> On Thu, Jul 17, 2008 at 05:36:05PM -0400, Dean Landolt wrote:
>> Or CLucene (for those of us with a violent distaste for all things Java). I
>> just learned about a new FTI option: Hyper Estraier -- also GPL, sadly, but
>> according to some benchmarks I stumbled across a good bit faster than both
>> Xapian and Lucene. And the GPL issue shouldn't be an issue if we're not
>> distributing the bindings (hyperestraier has pure-python bindings in PyPI
>> (that pyndexter already uses)).
>
> Does this not apply to Xapian too?
>
> What is the problem with the GPL as long as we don't distribute the bindings?

It depends on what license the bindings are released under. Assuming
they're GPL'd like Xapian's then the answer is that we distribute
separately. To me that's a slight annoyance. Pyndexter appears to be
under a BSDish license judging from the COPYING file. Not that I read
it, but it looks like the same format and length.

>
> --
> Noah Slater, http://people.apache.org/~nslater/
>

Re: the search api?

[Noah Slater <ns...@apache.org>]

On Thu, Jul 17, 2008 at 05:36:05PM -0400, Dean Landolt wrote:
> Or CLucene (for those of us with a violent distaste for all things Java). I
> just learned about a new FTI option: Hyper Estraier -- also GPL, sadly, but
> according to some benchmarks I stumbled across a good bit faster than both
> Xapian and Lucene. And the GPL issue shouldn't be an issue if we're not
> distributing the bindings (hyperestraier has pure-python bindings in PyPI
> (that pyndexter already uses)).

Does this not apply to Xapian too?

What is the problem with the GPL as long as we don't distribute the bindings?

-- 
Noah Slater, http://people.apache.org/~nslater/

Re: the search api?

[Dean Landolt <de...@deanlandolt.com>]

On Thu, Jul 17, 2008 at 5:12 PM, Paul Davis <pa...@gmail.com>
wrote:

> Heya,
>
> Yeah, the Xapian GPL stuff is kind of a PITA. Lucene would also be an
> option for getting around dumb legalities.


Or CLucene (for those of us with a violent distaste for all things Java). I
just learned about a new FTI option: Hyper Estraier -- also GPL, sadly, but
according to some benchmarks I stumbled across a good bit faster than both
Xapian and Lucene. And the GPL issue shouldn't be an issue if we're not
distributing the bindings (hyperestraier has pure-python bindings in PyPI
(that pyndexter already uses)).

And oh holy cow, pyndexter looks pretty interesting after reading the
> first paragraph. If it doesn't suck underneath the hood it'd be a
> pretty good way to allow people to use whichever engine they want.


I've been poking around under the hood and it looks pretty well thought out.
I don't like the fact that there hasn't been a commit on it in almost a
year, but it's probably better than starting from scratch. The code is
clean, logical and very well documented. Queries are even based on a uri
model, and the queries themselves get broken out into a parse tree that can
be reassembled specifically for any FTI engine.

The only thing with the FTI is that the future of how we couple
> external software to couchdb is in a state of uncertainty. Between
> plugins and action servers etc, I was going to wait till there was
> something more steady in place before attacking this full force.


Action server? That's a new one -- I'll poke around the listserv for more on
this...

The _search url was taken out for the 0.8 release. It should still be
> in the lucene branch though. Hacking it back into trunk should be a
> fairly trivial patch.


I'll have to find the time to experiment. I'm a little iffy on hacking on
the couch source for now -- frankly I'm afraid learning Erlang might take me
down a rabbit hole I don't have the time for at the moment. Like you, I'd
just as soon wait for some consensus on an api. At least now I have the
tools to be ready when this starts to bubble to the surface. Thanks for the
info Paul...

Dean

Re: the search api?

[Chris Anderson <jc...@grabb.it>]

On Thu, Jul 17, 2008 at 2:12 PM, Paul Davis <pa...@gmail.com> wrote:
> The only thing with the FTI is that the future of how we couple
> external software to couchdb is in a state of uncertainty. Between
> plugins and action servers etc, I was going to wait till there was
> something more steady in place before attacking this full force.

The main question for CouchDB's code is the stdio json protocol. Once
that is nailed down, attaching various indexers should be
straightforward. There are some design questions here, mostly to do
with consistency with the rest of CouchDB. Eg: the view servers are
fed a json array followed by a single newline, but search expects an
object followed by two newlines. I haven't looked at the
DbUpdateNotificationProcess but we should try to make that the same as
well.

I'm not sure if there are opportunities for code reuse here, but if
there are we should take them.

Chris

-- 
Chris Anderson
http://jchris.mfdz.com

Re: the search api?

[Paul Davis <pa...@gmail.com>]

Heya,

Yeah, the Xapian GPL stuff is kind of a PITA. Lucene would also be an
option for getting around dumb legalities.

And oh holy cow, pyndexter looks pretty interesting after reading the
first paragraph. If it doesn't suck underneath the hood it'd be a
pretty good way to allow people to use whichever engine they want.

The only thing with the FTI is that the future of how we couple
external software to couchdb is in a state of uncertainty. Between
plugins and action servers etc, I was going to wait till there was
something more steady in place before attacking this full force.

The _search url was taken out for the 0.8 release. It should still be
in the lucene branch though. Hacking it back into trunk should be a
fairly trivial patch.

Anyway, hope that helps. Feel free to shout if you have other
questions, or if I haven't managed to answer the original ones.

Paul

On Thu, Jul 17, 2008 at 4:57 PM, Dean Landolt <de...@deanlandolt.com> wrote:
> Paul Davis' work on integrating couch and
> xapian<http://code.google.com/p/couchprojects/source/browse/trunk/query_servers/xapian/README?r=23>seems
> like a good jumping-off point. But it seems to me it would be great if
> I could do something like this with an abstraction layer between couch and
> the search software (as an added bonus the code wouldn't have to be GPL'd
> and could be distributed with couch). From what I can tell
> pyndexter<http://swapoff.org/wiki/pyndexter/docs>looks like a nice
> option -- it's got a great API and even has its own
> built-in engine (pure-python, so slow, but no additional deps). Plus
> pluggable multilingual stemming and a nice query syntax, etc...
>
> I'm going to see if I can't turn this into a generic middleware layer that
> can catch couch's updates on stdin to update the index, but I don't even
> know where to begin in connecting the query server. From what I gather,
> there's no longer a /db/_search api -- how are these calls supposed to be
> invoked? Any information would be fantastic. Couch has proved everything
> I've wanted and more -- but I'd kill for a servicable search option...
>
> Dean
>