Andreas Junghans <[EMAIL PROTECTED]> writes: > Where's the difference between qx.core.ServerSettings.serverPathPrefix and > qxrpc_serverPathPrefix (apart from the global namespace pollution of the > latter)?
Hi Andreas, There's no difference except that one method puts code into qooxdoo that is really not generic. However, I don't have a strong opinion about this and it sounds like you do, so I won't belabor the issue. >> Andreas, I've been thinking about this. Although the specific case you >> require, an instance id, is more specific than I feel belongs in the RPC >> protocol, I can foresee a desire in various applications for being able to >> send some generic "out of band" data from the client to the server. Here's >> an alternative to passing the out-of-band data in the query string as we >> had discussed doing with the instance id. Let me know what you think of >> this. > > Looks like a nice addition. However, I still think we should treat an > instanceId as a special case. At least in the Java implementation, the id of > a server-side object is an integral part of object lookup (at least it was > before your patch ;-)). To get the same functionality without support for it > in the qooxdoo core would mean subclassing the RPC servlet in your > application (since you have to modify the internal object lookup). Why make > it harder for developers than it has to be? > > I just tested moving the instanceId to the URL, and it works fine, so I > don't have a problem with that. To support this model, the makeServerURL > function discussed above would get an additional optional parameter for the > instance id. This looks like a good solution to me, and I can contribute the > necessary code (both on the client and the Java side). However, I'd rather > not hide this id inside a generic server_data attribute (which is nice idea > on its own). Ok, that's fine. Just please don't add it to the call interface. Implement it as a property or something so that it's only accessed by applications that care about it. You can either send your changes to me, or just wait until I check in all of my stuff and then add to it. I hope to do my check-in tonight. I'll leave the serverData stuff in, too. > Even if several other backends have no notion of objects, instances and the > like, why make it harder for the Java case (and possibly PHP - doesn't PHP > have sessions and objects that can live inside these)? Absolutely! But your session is determined by a cookie. The application doesn't need to manually send stuff to indicate which session it's talking to. Is that what this instance id is really for? Why isn't it maintained in a cookie? It can/should (I think) be completely transparent to the caller if you're using it to identify a session. I'm glad we've homed in on an agreeable solution! It'd be nice if we could convince Danny, for a unanimous decision among the participants in the discussion. :-) Cheers, Derrell _______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
