On Fri, May 9, 2008 at 1:34 PM, Brian Eaton <[EMAIL PROTECTED]> wrote:
> On Fri, May 9, 2008 at 10:27 AM, Kevin Brown <[EMAIL PROTECTED]> wrote: > > This is probably useful, but I'm hesitant on the namespace -- if a > > standardized "auth" feature emerges, we'd have a conflict. I think this > came > > up before. Perhaps we should make all shindig implementation packages > name > > an underscore suffix to avoid this? Something like gadgets.auth_. We > could > > even put it under the "shindig" namespace to really avoid conflicts (and > we > > could migrate gadgets.config to this as well). > > I don't like gadgets.auth_, but shindig.auth sounds good to me. > gadgets.securityToken or shindig.securityToken would be fine with me > as well. > > One of my concerns about the javascript libraries in general is that > it's a little unclear what Shindig integrators can and can't depend > on. If I pull the security token out of the URL, who am I going to > break? The java code is changing frequently, but at least it gives a > compiler error when interfaces change. Everything that's standardized can, of course, be depended on. The stuff that isn't probably shouldn't be. One issue here is the lack of unit tests for the javascript. There are a few people working on addressing this by having a test runner that can be used to run jsunit tests. Of course, that still doesn't help in situations like these. Compliance tests like the opensocial compliance suite, which is just a gadget are probably the right answer here.
