David Leangen wrote: > Hmmm... Personally I'd be careful about not adding in too much stuff right > now. > > Maybe better to really have a sharp and limited focus at first and get that > "right" before widening the scope too much. > > Man, the project is already huge as far as I'm concerned. The hard part is > not writing the code, it's changing people's attitudes. I think we should > try to concentrate on that as soon as possible. Then we can go back and add > sugar like REST support.
Well, first of all when I say "built-in" I really meant it to be an extension rather than in the core API, so if you don't want it, that's ok. I think the idea of ensuring that the API is REST-friendly is important though. For example, one guy at the conference suggested that queries should be accessible as HTTP resources, which would mean that they are by default cacheable by proxies, repeatable through web "API"'s (HTTP requests), and so on. There can be quite a natural fit between what we do and the REST-model. I agree that going too far right now might be counter-productive though, and it's not easy to see what is really important right now and what is not. For example, the RMI EntityStore is also an "implementation detail", except that having it allow client code to be written as though it is running on the server and avoids the whole value object shuffling, which is soooo important. There's also the question of exactly what supporting REST means. For example, maybe it doesn't have to do at all with exposing data, but only exposing the RDF metadata about the application, as has been discussed, in order to make debugging tools easier to write, which in turn will make adoption easier and more attractive. Any more thoughts on this? /Rickard _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
