On Sat, 2009-01-10 at 18:20 -0700, Justin Deoliveira wrote:
> Hi all,
>
> I spent this last week looking at the rest config module in preparation
> in moving it toward supported. First off I want to say I really like
> restlet, and in particular the framework David has set up in GeoServer.
> It is quite easy to use and understand. That said I do think there is
> room for improvement. Here are some of the higher level things i have
> come up with.
>
> * Old Configuration / Catalog API
>
> All the code is written against the deprecated configuration api. A
> while back when I did an initial review I brought this up and the
> response was that this would be something we would look at when moving
> rest config to supported, but for the purposes of experimentation we
> would just write against the old api. Well that time has come.
>
> In my opinion the code should work against the new api. I don't think it
> makes a lot of sense to release the code when we know it will need a
> major overhaul shortly after. Now at first thought this would require a
> lot of work, however i have some other suggestions below that will save
> a lot of the work.
>
> * Reflection vs Maps
>
> Currently "resources" in rest config all extend from a generic class
> called MapResource. MapResource works by having subclasses transform an
> object (say a FeatureTypeInfo) into a map, and vice versa.
>
> While this approach is straight forward and simple I think a reflection
> based approach would result in a lot less code. Especially for the new
> catalog and configuration interfaces. We all ready have a bunch of
> reflection utility classes (used by the ows dispatcher and xml parsers).
> And Andrea even made them fast by introducing a cache.
>
While such a resource would probably be useful in a quick release, I am
not sure it should be used in the final version of the API. For
example, the current API proposal specifies the path to a datastore as:
/workspaces/{wsid}/datastores/{dsid}
Since workspaces are equivalent to namespaces (for the time being) we
should exclude the namespace from the returned representation of the
datastore. Similarly, redundant info such as the lat/long vs. native
bounds for featuretypes should be omitted (so we don't have deal with
self-inconsistent representations).
If we use a reflective implementation of the resources, I assume we will
be either exposing all attributes of configuration objects, or
blacklisting attributes to be hidden. I think it would be more safe
against future changes to the GeoServer catalog API to continue to use a
whitelist approach.
> Anyways, I think having a MapResource around is definitely useful for
> some cases, but I think another base class called something like
> "ReflectiveResource" would also be useful.
>
> * Serialization and De-serialization via XML and JSON
>
> An even bigger win with the reflective approach would be the
> serialization/de-serialization as XML and JSON via xstream. We already
> has code that does this as part of saving the configuration as xml with
> xstream. The exact same code can also be used to serialize as json with
> one flag set. So that basically means we don't have to write any custom
> serialization or de-serialization code. It also has the nice side-effect
> that when we output a resource via rest, it matches how we save the
> resource to disk.
>
> * Freemarker Templates for HTML output
>
> Currently when a resource is serialized as html it uses a built-in
> template. I think it makes sense to make this customizable for users
> with our fancy template system. I don't think this will be too much
> work. Basically just configure the template configuration used by
> FreemarkerFormat to use the GeoServerTemplateLoader to find a template,
> and fall back on the built-in templates.
I don't see a use case for this. Could you elaborate on why this would
be a good feature to have?
> Thats it for now :).
>
> -Justin
>
------------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It is the best place to buy or sell services for
just about anything Open Source.
http://p.sf.net/sfu/Xq1LFB
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
