[Foss4g2009] OCS/Events Conferencing software integration meeting minutes

[mapbutcher]

Hey,

I'd like to think we can approach this pragmatically and avoid over
complicating things. Lets concentrate on what it is we want the conference
website to achieve, keeping in mind our theme of 'user driven':

   - Attract people to the conference
   - Provide information about Sydney/Australia and what people can do and
   see while they are at the conference (other than attend sessions/workshops
   etc)
   - Provide accommodation information
   - Provide a single source of information on what it will be like to
   attend the conference
   - Registration
   - Paper Submission
   - Program\Schedule
   - Conference timeline
   - Contact/query info
   - ....

We have limited resources and IMO we don't want to be using these on
integration projects when we could possibly make a pragmatic decision now.
Personally I still haven't heard a convincing argument for complicating the
provision of the site by integrating two systems together. Should the local
committee vote on the whether we:

   - Use either the Tour Hosts system or OCS exclusively - both are
   providing adequate sites for conferences currently
   - If we are going to integrate the two systems together then make a
   decision on the level of integration.

I'm willing to put in time towards the website (sorry not 1-2 months PHP
hacking :), I'll even make the effort to get to Sydney if needs be, but I
would prefer to know that the time is not wasted on an integration that
serves no other purpose than saying we have used open source conference
software, especially taking into account previous comments on future reuse
of any integration efforts.

I vote for one system or the other, if that's not the way that the committee
wants to go then I would vote for as basic an integration as possible.

Cheers

Simon

2008/8/5 Cameron Shorter <cameron.shorter at gmail.com>

> Rrank,
>
> Gavin & Graeme explained the idea and hopefully will correct my
> interpretation of a proposed implementation:
>
> * OCS will accept user initial registrations.
> * OCS will pass registration details to Tour Hosts' "Events" package, and
> get a userId returned. (API needed here).
> Events package will process finances.
> * OCS will be able to query Events package to determine financial status of
> each member (by passing in the userId). (API needed here). This could be a
> push or pull interface, yet to be determined.
> * OCS will be responsible for processing papers and collecting information
> about delegates.
> * Events system is responsible for processing financial details, booking
> accommodation, and other things I can't remember.
>
> Indeed, this work could be quite simple if you have developers who are
> already familiar with the code base. People on the teleconference didn't
> have much experience in PHP.  So yes, with the right hackers, this could be
> done much cheaper that my estimated 1 to 2 months. Do you have such a hacker
> in mind?
>
> Frank Warmerdam wrote:
>
>> Cameron Shorter wrote:
>>
>>> The proposed solution is to use OCS for collecting presentations, and
>>> some of the registration work flow, then hand the rest over to the ICS
>>> software. (I haven't captured all the details here. Will leave that to
>>> someone else). Changes will likely be written in PHP & MySQL, plus
>>> contractors might need to be hired to provide hooks into the Events system.
>>>
>>
>> Cameron,
>>
>> I don't really have a clear understanding of the integration proposed.
>>
>> My past suggestion has been to handle the presentation collection and
>> management through OCS (something we have experience with), and handle
>> registration completely in the service providers system.  I don't see how
>> this would require any expensive integration.
>>
>> This still leaves some question about whether the "front end" web site
>> is managed by the local service provider's system or OCS.  I'm ambivalent
>> on this issue.
>>
>> In my optimistic opinion the only integration needed between the systems
>> should be an url at the appropriate points.  I will acknowledge that
>> users may end up with two userids if they are presenting, one to
>> register and one for the presentation management system.
>>
>> The objective - at least in the long term - is to get cheaper service from
>> the service providers since they won't be expected to manage the
>> presentation
>> aspect, and to ensure greater continuity of operation in this aspect.
>>
>> The only integration I anticipate is working to ensure OCS uses the OSGeo
>> LDAP database so that userid/password info is "OSGeo standard".
>>
>> Best regards,
>>
>
>
> --
> Cameron Shorter
> Geospatial Systems Architect
> Tel: +61 (0)2 8570 5050
> Mob: +61 (0)419 142 254
>
> Think Globally, Fix Locally
> Commercial Support for Geospatial Open Source Solutions
> http://www.lisasoft.com/LISAsoft/SupportedProducts.html
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/foss4g2009/attachments/20080806/b12a7a83/attachment-0001.html