(moving to the GeoNode list) Context is: how do we get GeoNode to sync its web application with GeoServer when, for example, a remote batch uploading utility is used to pipe a lot of data to GeoServer.
> Having things update in GeoNode automatically when new things are in >> GeoServer could be as simple as running a shell script or pinging some >> service PubSubHubBub style, either on uploads or periodically. >> > > Ok. I guess that as part of the Batch Upload work (which the Suite team > is in-kinding part of), GeoNode team should add this as a feature. > > I'll get that onto Trac, but I don't know how timing should work out. > > I just listed four possible solutions to this problem (run script or ping > web service, on upload or periodically). Which one are we adding as a > feature? > Yeah, good question. Which do you think would be best? I think the upload-event PubSubHub style service sounds the best to me, since my guess is that shell script would add deployment overhead that wouldn't be usable outside of a GeoNode context and syncing on a schedule as opposed to on events would make testing harder. > On Thu, May 20, 2010 at 3:01 AM, Andrea Aime <[email protected]>wrote: >> >>> Chris Holmes ha scritto: >>> >>> >>> I'd say let's cross that bridge when we come to it. Just keep good >>>> abstractions so that the file transfer is decoupled from the rest of the >>>> process. So that we could later put a more web friendly interface on top >>>> of >>>> it, possibly a chunking REST one. But I think we'll have to make a >>>> decision >>>> to go that direction, and then Tim will likely build the front end, and can >>>> design the server API so it works best for him. >>>> >>>> Thinking about other abstractions, the other awesome one could be smb. >>>> Schuyler suggested this - so people can just drag files over to a folder on >>>> their desktop. Only java implementation I could find is >>>> http://freshmeat.net/projects/jlanserver/ Also does FTP. Might be >>>> worth investigating - I think SMB would be a really nice bonus. >>>> >>> >>> The software seems to have become part of Alfresco, the license >>> is.. odd? Especially since they put it as a click through in the >>> download process: >>> >>> http://www.alfresco.com/products/aifs/download/ >>> >>> But the you get to sourceforge and the sources you can download there >>> have a GPLv2 + FLOSS exception licensing clause as far as I can see: >>> >>> /* >>> * Copyright (C) 2006-2008 Alfresco Software Limited. >>> * >>> * This program is free software; you can redistribute it and/or >>> * modify it under the terms of the GNU General Public License >>> * as published by the Free Software Foundation; either version 2 >>> * of the License, or (at your option) any later version. >>> >>> * This program is distributed in the hope that it will be useful, >>> * but WITHOUT ANY WARRANTY; without even the implied warranty of >>> * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the >>> * GNU General Public License for more details. >>> >>> * You should have received a copy of the GNU General Public License >>> * along with this program; if not, write to the Free Software >>> * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA >>> 02110-1301, USA. >>> >>> * As a special exception to the terms and conditions of version 2.0 of >>> * the GPL, you may redistribute this Program in connection with >>> Free/Libre >>> * and Open Source Software ("FLOSS") applications as described in >>> Alfresco's >>> * FLOSS exception. You should have recieved a copy of the text >>> describing >>> * the FLOSS exception, and it is also available here: >>> * http://www.alfresco.com/legal/licensing"; >>> */ >>> >>> I can see a user forum but not a developer mailing list... hmmm... >>> smells like the usual "fake open source" project to me, the >>> license is there, the community is not. >>> First sign of trouble and they'll ask us to get a support contract... >>> hum... where do I have already seen that? :-p >>> >>> Anyways, I'll have a deeper look, right now I don't really see >>> a quick way to embed that thing. >>> >>> >>> Long story short, a reliable data transfer can be implemented >>>>> only on trunk and only after some modifications to GeoTools. >>>>> It's not something we can do well on the current stable series, >>>>> unless we just target PostGIS as the one and only target >>>>> >>>>> >>>> I'm fine with PostGIS as the one and only target. It's the suite >>>> default. If we get people asking for oracle/arcsde we can tell them it's >>>> in >>>> the next release. But I don't think we should not do the import to db just >>>> because those don't work. We could set it up so you can't set DBs other >>>> than oracle as the default. Or at least caveat heavily. If it's just some >>>> name mangling I don't think that's so bad. >>>> >>> >>> Ok, that was one issue, the other is that the concept of >>> default store in GeoServer required quite a bit of changes at the >>> catalog and REST config level and is available only on GS trunk. >>> >>> So if you want this no 2.0.x we'll also need people to explicitly >>> tell us to which datastore we have to perform the import. >>> >>> >>> Cheers >>> Andrea >>> >>> >>> -- >>> Andrea Aime >>> OpenGeo - http://opengeo.org >>> Expert service straight from the developers. >>> >>> >>> -- >>> Archive: >>> http://lists.opengeo.org/opengeo-team/archive/2010/05/1274338864511 >>> >>> To unsubscribe send an email with subject "unsubscribe" to >>> [email protected]. Please contact [email protected] >>> questions. >>> >> >> >> >> -- >> Sebastian Benthall >> OpenGeo - http://opengeo.org >> >> >> >> -- >> Archive: >> http://lists.opengeo.org/[…]/1274725993513<http://lists.opengeo.org/opengeo-team/archive/2010/05/1274725993513> >> To unsubscribe send an email with subject "unsubscribe" to >> [email protected]. Please contact [email protected] for >> questions. >> >> >> >> >> -- >> Archive: >> http://lists.opengeo.org/[…]/1274726564413<http://lists.opengeo.org/opengeo-team/archive/2010/05/1274726564413> >> >> To unsubscribe send an email with subject "unsubscribe" to >> [email protected]. Please contact [email protected] for >> questions. >> >> >> > > > -- > Sebastian Benthall > OpenGeo - http://opengeo.org > > > > -- > Archive: > http://lists.opengeo.org/[…]/1274727265017<http://lists.opengeo.org/opengeo-team/archive/2010/05/1274727265017> > > To unsubscribe send an email with subject "unsubscribe" to > [email protected]. Please contact [email protected] for > questions. > > > -- Sebastian Benthall OpenGeo - http://opengeo.org
