Hello Bram,
On 20 Jun 2011, at 17:21 , Bram de Kruijff wrote:
> On Mon, Jun 20, 2011 at 12:52 PM, Marcel Offermans (JIRA)
> <j...@apache.org> wrote:
>
>> So an interaction with the server could start somewhat like this:
>>
>> POST /ace/client -> sessionid
>> This will trigger a basic authentication, which, if it succeeds, will return
>> a session id. It makes sense to also implicitly do a checkout.
>
> Should probably return full url not just id (and provide location
> through 301) for nice hateoas
My idea was that this could just as well be a relative URL (just like you can
have those in an HTML page), but maybe in this case (the POST request that
creates something new) it makes sense to return a full URL (when GETting long
lists of items, relative URLs sound a lot more appealing to me).
> Does vaadin client at this point uses one session not bound to user or
> is getNewApplication invoked for every new jsession?
In Vaadin, the Application IS the session (ie, you're not exposed to web
sessions, you can assume each application is a session). That's not bound to a
user (in fact, probably most Vaadin applications don't even have the notion of
a logged in user).
> Premature performance/resource concerns: Does the current impl scale
> up to large repositories and many sessions?
I can only give you a premature answer here, and that is that various people
tried out Vaadin with large numbers of sessions and found no fundamental issues
with it.
We did not test that yet, and to be honest, I don't expect a lot of concurrent
users to manipulate a single repository. Typically that might be the task of
only a handful of people.
>> GET /ace/client/mysessionid/feature -> list of feature id's
>> Will return a list of features in the repository.
>
> In general there is no id on RepositoryObject in the model?
Correct. In fact, in some places, our handling was even a bit inconsistent.
Karl just fixed an issue in that area, see ACE-149.
> How would you map this? Eg. for associations?
We will have to come up with some kind of identity for associations. Probably
these will be little more than a unique ID. In the OSGi service API we just use
instances so there we avoid the issue. We might have to revisit that a bit.
>> PUT /ace/client/mysessionid/feature/MyCustomFeature
>> Will create a new feature with a unique id called "MyCustomFeature". Maybe
>> the put will also contain some (JSON/XML) data to describe the feature.
>
> The this id is the getNameI()?
Yes.
> Are there restrictions imposed/assumed on names?
Names are used in OSGi filter conditions, and should be unique. We'll have to
URL encode them for REST I guess.
> Would prob be nice to support both xml and json. See you already use
> xstream could we easily reuse the mapping? For json gson might be a
> nice fit.
I'm not sure if we want to make the way we map our entities to XML part of the
public API. I'll take a look at gson, but can you explain why you would use it
here over the many other json libraries out there?
>> In general, we can map all our entities (artifacts, features, distributions
>> and targets) as well as all our associations (artifact2feature,
>> feature2distribution, distribution2target) to REST endpoints that are very
>> similar, so:
>> /ace/client/<sessionid>
>> /artifact
>> /feature
>> ...
>>
>> And for each of those repository objects (as they're called in the code) we
>> can do things like:
>>
>> GET /ace/client/<sessionid>/<repositoryobjecttype>/<objectid>/tag
>> To get a list of all tags associated with object "objectid".
>>
>> PUT
>> /ace/client/<sessionid>/<repositoryobjecttype>/<objectid>/tag/description
>> "This is a description."
>> To set/replace the description tag.
>
> Why go beyond a resource per entity type? Ease of use and/or performance?
Hmm, maybe you're right here, I don't think it makes much sense to do that.
>> Finally, for the 'checkout', 'revert' and 'commit' commands, we could do
>> something like this:
>>
>> GET /ace/client/<sessionid>/{commit,revert,update}
>> Which will return success or failure.
>
> Guess that so be a PUT of some sort with GET being idempotent and all.
I think Angelo and Karl had some feedback on this as well (I'll reply to that
one next).
> Anyhow, a nice exercise in getting to know the ace model for now. Let
> me know if I can help out somehow.
I think you just did! :) Seriously, after the design discussions on this have
died down, I'll have a go at implementing this. Feel free to jump in there at
any time. And thanks so far!
Greetings, Marcel
