+1

On Tue, Apr 24, 2012 at 11:22 AM, Andrea Aime
<[email protected]> wrote:
> Hi,
> nowadays all CatalogInfo objects identifier is generated by using the object
> type plus a local UID:
>
>             String uid = new UID().toString();
>             OwsUtils.set( o, "id", o.getClass().getSimpleName() + "-"+uid );
>
> I'm looking into a user case where it would be beneficial, instead, to use a
> plain UUID, that is,
> something like:
>
>             String uuid = UUID.newRandomUUID().toString();
>             OwsUtils.set( o, "id", uuid);
>
> The rationale for the change lies in organizations that have several
> GeoServer installed
> and in use, by different departments, controlled by different people, and
> running different
> versions (the case I'm looking at has 20+ GeoServer installations maintained
> under separate
> admins, with no short term opportunity to consolidate them in a single
> install that has
> the same version and plugin set for everybody).
>
> To provide a little management to the above situation they want to at least
> have a
> centralized catalog that contains info about all the servers, a catalog that
> uses
> RDF style triplets instead of the classic Geonetwork harvesting.
>
> Each GeoServer would then be equipped with a simple catalog listener that
> informs the central
> catalog about new layers, in such a way that renames do not affect the
> central system,
> thus the idea to use UUIDs to identify each layer.
> Those could be generated by a separate plugin and stored in the metadata map
> of each
> CatalogInfo object, but it would be just simpler if the ids were UUIDs in
> the first place.
>
> Since we never advertised the GeoServer internal ID format it would not be a
> breaking change,
> and in fact all that we want is uniqueness, not a particular format.
> Switching to UUID would also be helpful in situation where we have a
> GeoServer cluster in
> multi-master configuration, as it would ensure the different masters cannot
> come up with
> the same ID for different objects.
>
> The change would affect only trunk.
>
> Opinions?
>
> Cheers
> Andrea
>
> --
> -------------------------------------------------------
> Ing. Andrea Aime
> GeoSolutions S.A.S.
> Tech lead
>
> Via Poggio alle Viti 1187
> 55054  Massarosa (LU)
> Italy
>
> phone: +39 0584 962313
> fax:      +39 0584 962313
> mob:    +39 339 8844549
>
> http://www.geo-solutions.it
> http://geo-solutions.blogspot.com/
> http://www.youtube.com/user/GeoSolutionsIT
> http://www.linkedin.com/in/andreaaime
> http://twitter.com/geowolf
>
> -------------------------------------------------------
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Geoserver-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>



-- 
Gabriel Roldan
OpenGeo - http://opengeo.org
Expert service straight from the developers.

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Reply via email to