On 03/30/2012 04:38 PM, Julien Viet wrote:
Hi Nick,
here are my initial comments remarks
1/ for pagination I see "page=2&per-page=10" can it work
in a reliable manner with concurrency ? (i.e if I go on page 2
and someone added a result meanwhile).
No it cannot unless we keep state on the server. See my discussion
point on this, where we can pass a token back to the client which
could expire if the collection has changed. Atom spec just says that
results are lossy, see
http://tools.ietf.org/html/rfc5005#section-3.
We may just go with this approach for first iteration.
2/ at some point there will a few improvements in application
management, in particular we should have the capability to scope
applications per site (like pages and navigations). The current
proposal to use
/applications/app-type/app-id
will be an issue as it will not be possible to scope an
application to a site.
So we will have applications that are "global" and some that are
specific to a site ? I'll have to think about this.
And the existing application registry should be seen as a
"parent" registry.
Do you mean instead of /registry/applications it should just be
/appregistry ?
3/ for site based API : why do we have the scheme
/something/site-type/site-name/foobar and not
/sites/site-type/site-name/concern/foobar ?
this would enable to have /applications per site (see remark
2) and have a global /applications for current application
registry without conflicts.
This is how I organized the resources for gatein management and
something I am interested in hearing from others. I think it makes
sense to represent it this way and /pages, etc are more just search
views that eventually link to
/sites/site-type/site-name/concern/foobar.
So for example /pages = [
{
"site-type": "portal"
"site-name": "classic"
"page-name": "homepage"
"link": {
"href" : "/sites/portal/classic/homepage"
"rel" : "gtn:page"
}
},
...
]
4/ the current model for application registry is broken and
prevents to do a correct API (java or rest). I want to change
that for the next major version, you should be prepared to this
change.
We should be able to design the API on how we see this looking right
? In other words the API can be the use case on making the
underlying model and implementation better.
Basically an application is seen in the application registry
as en entry of /production/app:applications/category/application
but the corresponding configuration application is a node under
/production/mop:workspace/mop:customizations/application
For instance
"/production/mop:workspace/mop:customizations/mop:Todo"
and
"/production/app:applications/app:Gadgets/app:Todo"
This is broken because an application can be described twice
with different data, i.e there can be several entries under
app:applications/* that can point to the same customization (the
real application).
Worse than that the same application can appear twice in the
application registry with different security permissions.
I want to fix this and instead remove the application part of
the app:applications.
Instead use mixins to put on a customization to add the data
that will describe it (i.e enhance it) with the mixins
gtn:described and gtn:protectedresource we have already in
gatein.
The whole customization's thing for the MOP is confusing. Can we not
make a generic application that has portlet and gadget mixins and
drop the whole customization thing ? I am not too familiar with this
and not sure if this even makes sense.
The app:applications would somehow remain but it would be a
simple relationship to the customization itself instead of en
entity. This would allow the same application to appear in
several categories. There would be a new mixin to make an
application point to several categories to put on an
application. This would provide the many-to-many relationship
between application and categories.
That's the only major changes I foresee so far in MOP for the
next major version.
On Mar 30, 2012, at 10:00 PM, Nick Scavelli wrote:
The initial draft of
the REST API specification is available now
https://community.jboss.org/wiki/GateInRESTAPISpecification.
I tried to design it as RESTful as possible for now, and
we can decide if some complexity that comes with REST is
appropriate for the GateIn REST API. For example Twitter's
REST API is fairly easy to understand, however some would
not call it quite so "RESTful".
Also this specification conflicts with the stuff I've
built for GateIn Management, especially the organization
of the resources (pages, navigation, etc). However we
should be in sync with how the Public Java API is going to
expose these resources. For example if I can do
api.getPages() as apposed to api.getSite().getPages() then
Pages should be a "first class resource".
All feedback is welcome.
- Nick
gatein-dev mailing list
gatein-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/gatein-dev