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

[Eli Adam]

Bob and Bob,

Are there reasons that you don't want to do editing with WFS-T?
http://www.geomoose.org/docs/vector_layers/geoserver_setup.html

Eli


On Wed, Jun 12, 2013 at 1:39 PM, James Klassen <klassen.js at gmail.com> wrote:
> 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] 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
>>>
>
> _______________________________________________
> Geomoose-users mailing list
> Geomoose-users at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/geomoose-users
>