On Thu, Jun 19, 2008 at 1:55 AM, Ian Boston <[EMAIL PROTECTED]> wrote:
> "sure, go and refactor it". makes a lot of sense to me as I can see other
> areas of the spec emerging which might need new service api's
>
> although I agree with Kevin's comment about the consumer knowing what the
> item is....
>
> 2 questions.
>
> Are you also going to have interfaces for the model, as IMHO having a
> service API that forces the implementor to use concrete classes owned by the
> consumer of that API means the API is semi concrete (did that make sense
> :))..... it would also make it easier to use a wider range of
> implementation strategies.
Oh geeze. I am a bad person for not doing this for so long, I know. Okay, so
I didn't apply your patch directly because it had too many inconsistent
style thingys that I knew would be faster to fix if I just got my ide to
pull the interfaces out super quickly. I should have just done this so long
ago. Anyway, I'm gonna check this in in round 30 min.
>
>
> and
>
> I trust that you are intending to do a default impl before fixing the API,
> just to see how it feels in the wild.
>
> Ian
>
>
>
>
> On 18 Jun 2008, at 23:57, Cassie wrote:
>
> Hey guys -
>>
>> So I was just starting to add a messaging service to the java code and I
>> saw
>> that the new java service interfaces still need a lot of cleanup. I also
>> noticed how similar they were to one another because of how structured the
>> rest calls have been making everything. So... I started thinking about a
>> generics based interface that could work for all of the different types of
>> objects we currently have and could hopefully extend to photos, movies,
>> etc.
>>
>>
>> Anybody want to give me some quick feedback on a simple service like this:
>>
>> // T is the type of model object that this service deals with. (I know,
>> crappy name, feel free to suggest a better one)
>> // T = Activity, Person, Message or Map<String, String> (ie Data)
>>
>> public interface ItemService<T> {
>>
>> public ResponseItem<RestfulCollection<T>> getItems(UserId userId,
>> GroupId groupId, String appId, Set<String> fields, SortOrder sort,
>> SortDirection direction, FilterType filter,
>> int first, int max, SecurityToken token);
>>
>> public ResponseItem<T> getItem(UserId userId, GroupId groupId, String
>> appId,
>> Set<String> fields, String itemId, SecurityToken token);
>>
>> public ResponseItem<T> deleteItem(UserId userId, GroupId groupId, String
>> appId,
>> String itemId, SecurityToken token);
>>
>> public ResponseItem createItem(UserId personId, GroupId groupId, String
>> appId,
>> Set<String> fields, T item, SecurityToken token);
>>
>> // None of the services have this right now... but it maps to "put" in
>> rest. Will we ever actually use this call?
>> public ResponseItem updateItem(UserId personId, GroupId groupId, String
>> appId,
>> Set<String> fields, T item, SecurityToken token);
>>
>> }
>>
>> Now Data doesn't -quite- fit with this model because it doesn't return a
>> List<T> it should return a Map<String, T> but yeah.. we can special case
>> that somehow for now or eventually be more standard and get rid of it. We
>> could also compose userId, groupId and appId into an object to remove some
>> of this overly large param list clutter or something...
>>
>>
>> Alright, so, "horrible idea I've lost my mind" or "so, so idea I don't
>> think
>> it'll work long term" or "sure, go and refactor it".
>> Thanks.
>>
>> - Cassie
>>
>
>
