[Foss4g2009] OCS/Events Conferencing software integration meeting
minutes
Cameron Shorter
cameron.shorter at gmail.com
Wed Aug 6 06:29:44 EDT 2008
In answer to some questions:
1. Simon, an OCS only solution is not an option as Tour Hosts' processes
are too closely integrated with their Events system. The best we can do
is integrate OCS with Tour Hosts' Events.
2. Bruce, I understand the Event's system is used around the world.
3. Bruce, the integration we are proposing is to allow sharing of user
ids between OCS and Events (use a Single Sign on). While there is
probably only a few days work for this specific functionality, I'd
expect to waste a lot of time getting the two systems to line up their
processes and hand over from one to the other smoothly, get code
submitted into baselines etc. (Hence the 1 to 2 months estimate).
I agree with sentiment so far. If a volunteer doesn't step forward, we
should go back to the safe option. And lets focus our energy of better
things.
Eg: A foss4g integration showcase:
http://wiki.osgeo.org/wiki/FOSS4G_2009_Integration_Showcase
Bruce Bannerman wrote:
> Some very good points Simon.
>
> From memory, Tour Hosts had some significant concerns relating to the
> integration of their Events software into their payments / bookings
> functionality in particular.
>
> During the Tender review process, I understood that we would not be
> changing this. Sorry if I'm going over old ground, I missed the meeting.
>
> Just what is it that we are trying to do with the integration that
> requires 1-2 months effort?
>
> More importantly, is Events Plus just an Australian product or is it
> used in the international events industry as well?
>
>
> Bruce
>
>
> On Wed, 2008-08-06 at 19:29 +1000, mapbutcher wrote:
>
>> 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
>>
>>
>>
>>
>> _______________________________________________
>> Foss4g2009 mailing list
>> Foss4g2009 at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/foss4g2009
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Foss4g2009 mailing list
>> Foss4g2009 at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/foss4g2009
>>
--
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
More information about the Foss4g2009
mailing list