[Geomoose-users] Services abstraction, what's the status of this?

Wed Jun 12 13:39:22 PDT 2013

Also, most of the items you listed are more appropriate as extensions than
services at least in so far as they interact with GeoMoose.

As an aside, some things that are now services may be moved into JavaScript
within GeoMoose if feasible.  Modern browsers are much better than the
situation was in 2006.  So things like printing, select, identify, etc. may
be doable in the browser and backed by WMS/WFS rather than needing direct
server side help.  This greatly simplifies the security model on the server
and also helps people who want to do incremental updates as it uncouples
GeoMoose version from MapServer version and allows things like multiple
MapServer versions, a mix of MapServer and GeoServer (or others) and having
layers sourced from different servers altogether (cloud like).
On Jun 12, 2013 3:31 PM, "James Klassen" <klassen.js at gmail.com> wrote:

> The short answer is users are encouraged to write their own services
> conforming to the GeoMoose service API to do whatever tasks are necessary
> in whatever environment best fulfills their needs.
>
> The GeoMoose project currently maintains some services in PHP.  I have
> implemented custom services (simultaneously compatible with multiple
> versions GeoMoose and other software) in Perl, Python, Ruby (CGI and
> Rails), and C over the years.
>
> There was talk at FOSS4G-NA and at the last PSC meeting about reworking
> the services that are included as part of the demo.  The primary reason is
> to remove some artificial limitation based around accessing local
> mapfiles.  This work would likely not be done in PHP.  However, this
> doesn't mean PHP services will stop working.  There is a published API for
> how GeoMoose interacts with services and there are no plans to break
> backwards compatibility with that API.
>
> Note, however, future demos (essentially a configuration) may be based on
> future default services, which may change some file layouts.
> On Jun 12, 2013 2:41 PM, "Basques, Bob (CI-StPaul)" <
> bob.basques at ci.stpaul.mn.us> wrote:
>
>>  Bob,****
>>
>> ** **
>>
>> Both would be supported, and more, Jim has indicated PYTHON as an option
>> as well.****
>>
>> ** **
>>
>> bobb****
>>
>> ** **
>>
>> ** **
>>
>> *From:* Bistrais, Bob [mailto:Bob.Bistrais at maine.gov]
>> *Sent:* Wednesday, June 12, 2013 2:22 PM
>> *To:* Basques, Bob (CI-StPaul); geomoose-users at lists.osgeo.org
>> *Subject:* RE: Services abstraction, what's the status of this?****
>>
>> ** **
>>
>> I’m a PHP user.  Since we have a number of applications built on
>> GeoMoose/PHP, I’m concerned- would I need to convert everything to Perl in
>> future upgrades, or do you mean that PHP AND Perl would be supported for
>> services?****
>>
>> ** **
>>
>> Certainly interested in the feature editing piece.  AVL is neat but I
>> think my anticipated needs would require feature editing more.****
>>
>> ** **
>>
>> *From:* geomoose-users-bounces at lists.osgeo.org [
>> mailto:geomoose-users-bounces at lists.osgeo.org<geomoose-users-bounces at lists.osgeo.org>]
>> *On Behalf Of *Basques, Bob (CI-StPaul)
>> *Sent:* Wednesday, June 12, 2013 3:00 PM
>> *To:* geomoose-users at lists.osgeo.org
>> *Subject:* [Geomoose-users] Services abstraction, what's the status of
>> this?****
>>
>> ** **
>>
>> All,****
>>
>> ** **
>>
>> So, I’m setting up a new install of GeoMoose (among other things, read
>> on) and wondering about where the services abstraction ideas are currently
>> at?  While I know PHP is popular, I much prefer PERL for the services side
>> of things.****
>>
>> ** **
>>
>> I would like to use PERL in place of PHP for example.  I just want the
>> option of using another language.  I know this has been talked about in the
>> recent past and I guess I’m looking harder at it now.****
>>
>> ** **
>>
>> So, ****
>>
>> **·          **Where in the release cycle is this capability at?****
>>
>> **·          **Should I (we) progress this internally first and then
>> just pass back to GeoMoose as a pass fail sort of endeavor for inclusion in
>> GeoMoose, or . . .****
>>
>> **·          **Put out a spec and ask for bids here?, or . . . ???****
>>
>> ** **
>>
>> I also have some more stuff coming down the line, but figured I would
>> start with the above first to get a conversation going here.****
>>
>> ** **
>>
>> --------------****
>>
>> ** **
>>
>> Future stuff:****
>>
>> **·          **Feature updating (PUSH) from a service.  (IE. GPS point
>> Tracking, and Weather overlays)****
>>
>> **·          **Alternate map Views (spawning service from GeoMoose) for
>> OpenLayers and 3D(HTML5) constructs, and other reporting packages . . .**
>> **
>>
>> **·          **Old timey (City of Saint Paul) Popup capabilities (some
>> of the GeoMoose developers know what I’m talking about here) or something
>> very close.****
>>
>> **·          **Addition of a optional service side (server component)
>> construct for handling of feature editing in GeoMoose.  I know this is a
>> whole new side of things, and it can become it’s own thing if need be,
>> project wise.  I haven’t started this here yet, but it’s next after AVL has
>> settled down. See next item****
>>
>> **·          **Addition of a AVL (location tracking) service (server
>> component).  I actually have this well on it’s way already and am wondering
>> about how to integrate it with GeoMoose as well as put the project out as
>> OpenSource, and with GeoMoose or on it’s own as a companion piece.  Does it
>> make and sense to put it under the GeoMoose project umbrella, or should it
>> be it’s own  thing?  My vote is to add it to GeoMoose in some form.****
>>
>> ** **
>>
>> Thanks****
>>
>> ** **
>>
>> ** **
>>
>> _______________________________________________
>> Geomoose-users mailing list
>> Geomoose-users at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/geomoose-users
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/geomoose-users/attachments/20130612/f3331b02/attachment.html>