> That's an interesting idea. I think it could work for most cases, but some > lower level API would be nice too, if greater flexibility is necessary.
Whatever we do, the "cookie" should never be manipulated directly. For Caja, it's important that we use an interface so that we can change implementation - as Kevin mentioned, Caja will not allow you manipulate a cookie directly. > For sites that are dependent on cookies, this would make porting to a > > gadget much easier. I'm sure there are more issues, e.g. cost of > uploading > > large cookies. > > Hmm, large cookies, didn't think about this... We could probably limit the > cookie size, but on the other hand I think slow gadgets will just die on > their own :) When a user removes a gadget (e.g. if it's slow or doesn't work), we use that information to drive ranking in the directory. That's a long feedback loop. To make the feedback loop tighter, we should provide better tools for developers. Checking the gadget DOM, intercepting makeRequests and so on, can all provide useful feedback. When a developer is adding their gadget to the directory, advising them that their image fetches aren't being cached and could swamp their servers, would be very helpful. Encoding those best practices into an automated tool would help developers a lot. -- > Best Regards, > Piotr Jaroszyński >
