<div dir="ltr">Hey,<br><br>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':<br>
<ul><li>Attract people to the conference</li><li>Provide information about Sydney/Australia and what people can do and see while they are at the conference (other than attend sessions/workshops etc)</li><li>Provide accommodation information</li>
<li>Provide a single source of information on what it will be like to attend the conference</li><li>Registration</li><li>Paper Submission</li><li>Program\Schedule</li><li>Conference timeline</li><li>Contact/query info</li>
<li>....<br></li></ul>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:<br><ul><li>Use either the Tour Hosts system or OCS exclusively - both are providing adequate sites for conferences currently<br></li><li>If we are going to integrate the two systems together then make a decision on the level of integration.<br>
</li></ul>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.<br>
<br>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.<br><br>Cheers<br><br>Simon<br><br><div class="gmail_quote">2008/8/5 Cameron Shorter <span dir="ltr"><<a href="mailto:cameron.shorter@gmail.com">cameron.shorter@gmail.com</a>></span><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Rrank,<br>
<br>
Gavin & Graeme explained the idea and hopefully will correct my interpretation of a proposed implementation:<br>
<br>
* OCS will accept user initial registrations.<br>
* OCS will pass registration details to Tour Hosts' "Events" package, and get a userId returned. (API needed here).<br>
Events package will process finances.<br>
* 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.<br>
* OCS will be responsible for processing papers and collecting information about delegates.<br>
* Events system is responsible for processing financial details, booking accommodation, and other things I can't remember.<br>
<br>
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?<div class="Ih2E3d">
<br>
<br>
Frank Warmerdam wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Cameron Shorter wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
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.<br>
</blockquote>
<br>
Cameron,<br>
<br>
I don't really have a clear understanding of the integration proposed.<br>
<br>
My past suggestion has been to handle the presentation collection and<br>
management through OCS (something we have experience with), and handle<br>
registration completely in the service providers system. I don't see how<br>
this would require any expensive integration.<br>
<br>
This still leaves some question about whether the "front end" web site<br>
is managed by the local service provider's system or OCS. I'm ambivalent<br>
on this issue.<br>
<br>
In my optimistic opinion the only integration needed between the systems<br>
should be an url at the appropriate points. I will acknowledge that<br>
users may end up with two userids if they are presenting, one to<br>
register and one for the presentation management system.<br>
<br>
The objective - at least in the long term - is to get cheaper service from<br>
the service providers since they won't be expected to manage the presentation<br>
aspect, and to ensure greater continuity of operation in this aspect.<br>
<br>
The only integration I anticipate is working to ensure OCS uses the OSGeo<br>
LDAP database so that userid/password info is "OSGeo standard".<br>
<br>
Best regards,<br>
</blockquote>
<br>
<br>
-- <br></div><div><div></div><div class="Wj3C7c">
Cameron Shorter<br>
Geospatial Systems Architect<br>
Tel: +61 (0)2 8570 5050<br>
Mob: +61 (0)419 142 254<br>
<br>
Think Globally, Fix Locally<br>
Commercial Support for Geospatial Open Source Solutions<br>
<a href="http://www.lisasoft.com/LISAsoft/SupportedProducts.html" target="_blank">http://www.lisasoft.com/LISAsoft/SupportedProducts.html</a><br>
<br>
</div></div></blockquote></div><br></div>