On 10/29/07, Torgeir Veimo <[EMAIL PROTECTED]> wrote: > ...Yes I guess the terminology is a bit confusing. A Resource is also > something used in WebDAV. But I guess the naming issue is done and > dusted already....
Yes, obviously Resource can mean different things, but in our quest to expose the REST style it seems to be the best name. We can always talk about a "Sling Resource" if we need to qualify it. > ...This is fine for new implementation. What if one need to implement > legacy services, where the url patterns used are different? > > Providing the request selector as the default mechanism is good. > Having it as the only mechanism is bad.... Agreed. Although microsling is not meant to be "user-extensible", it is sufficiently simple (and will be even smaller once it uses the sling-api that we're discussing here) that one can replace any part of it easily by extending classes. And in Sling OSGi, I guess pretty much everything can be replaced by way of OSGi bundles. > ...My preference would be to have > only one sling, where OSGi is optional though.... Considering the discussions in the last few weeks, it seems like we're headed for a lightweight microsling, meant mostly as an educational/demo tool but also usable for simple applications, and the full-blown Sling, based on OSGi, extensible, etc. Both are based on the same API, and the microsling code will be very small, so I think that's a good approach. But, depending on how people use microsling and Sling, we might migrate software components "down" or "up" until we find the right balance. -Bertrand
