[geomoose-psc] Version 2.7

[Eli Adam]

Hi All,

2.7 progress is really exciting!  I've been watching the updates fly by.

I think that we should send an email to the users list as well to let
people know that we are working on things and that testing and ticket
review and feedback would be helpful.  Which link should we send for
this?  Here are a few options:
https://github.com/geomoose/geomoose/issues?direction=desc&page=1&sort=updated&state=open
https://github.com/geomoose/geomoose/issues?direction=asc&milestone=1&page=1&sort=created&state=open
https://github.com/geomoose/geomoose/issues?direction=asc&labels=review&milestone=1&page=1&sort=created&state=open

I ran into a slight snag on sending a testing email which is that the
nightly downloads are not current, http://geomoose.org/download.html.

On Sun, Apr 27, 2014 at 4:22 PM, Dan Little <theduckylittle at gmail.com> wrote:
> Where We Are:
> - Massive progress towards tickets.  Most are in review.
>
> What We Plan to Finish:
> - Saint Paul has a few more sponsored enhancements that will start to
> percolate their way through over the next week.
> - Testing.  Most of those tickets have been tested and all tickets
> related to services have an automated test to prove they work (see
> geomoose-services/tests).

Nice!

>
> What is on the Table:
> - Cursor tickets.  Frankly, I'd rather just neuter the cursor ability
> once and for-all.  It doesn't work consistently across version of
> windows, it doesn't usually work well on webkit, and have been
> differing requests on how they /should/ behave based on how different
> folks feel state should be managed.  That said, I'm bitter and
> hateful, and would simply rather not do the work.

Cursor stuff seems needed in that there are numerous advanced
functions, if GeoMoose only did one thing with hover or click, well it
wouldn't be GeoMoose and cursor stuff would be unneeded.  I agree that
it is open for debate for what is "working".

> - Dean's "Like All" and "Like Any" enhancements to the query.php
> script.  I see how these are entirely useful and could completely
> punish a system.  They are some big inclusions that really grow the
> size of the file and I'm slightly worried about future management of
> that code (it's a bit messy, not to say their isn't other messes, but
> growing it is not always a good idea).  Looking ahead we should be
> trying to plan for a GeoMOOSE Unified Search that gives people a more
> google-esque behaviour to their search.  There is nitty gritty details
> (and some sponsorship would be nice) to get there but I'm on the fence
> about getting these in for 2.7.

I'm excited about this contribution since this moves us towards the
google-esque "type what you want in one box and get the results".
This is far better than the "learn a complex and obscure data schema,
then learn non-standard query methods to apply in exacting detail on
that obscure data schema."

I also agree with some of the comments here,
https://github.com/geomoose/geomoose/issues/35 that we are loading a
lot into this service, perhaps in a non-optimized way in some
situations.  But if we had tsearch
(http://www.postgresql.org/docs/current/static/textsearch.html) or
Solr we wouldn't have a lot of these services in this form.  However,
unless we abstract complex search away in some light format like
sqlite or DB abstraction layer like sqlalchemy then those are heavy
dependencies. Avoiding these dependencies has always been one of
GeoMoose's strong points and favored characteristics by many users.

"Type what you want in one box totally oblivious to the data schema
and search methods, (then inefficient convoluted search service), then
get results back (and perhaps managed or grouped by type)" is a great
step forward.  Ideally, the "inefficient convoluted search service"
will down the road become "fancy abstracted efficient and industry
standard search service without adding onerous dependencies"

> - I need to look at Joe's updated pull request.  I may need to bounce
> it back to him again after all the changes to master.

Ticket 35 was based off of truck without Joe's pull request.  Dean did
it twice, once based off of Houston's work and then once based off of
trunk so that he was able to apply it to both, but the goal is to get
it in core and work with it there.

Best regards, Eli

>
> Jim, maybe you've got some more ideas on where/when.  Eli, always
> interested in your feedback here too.
> _______________________________________________
> geomoose-psc mailing list
> geomoose-psc at lists.osgeo.org
> http://lists.osgeo.org/cgi-bin/mailman/listinfo/geomoose-psc