On 25/08/10 15:10 -0400, Phillip Heller wrote: > Greetings, > > After some discussion today with Tobias in IRC, I decided to share some > thoughts on implementation of Custom URL handlers for Tryton. > > An initial pass at the structure: > > tryton:/[/[username[:passwo...@]server[:port][/protocol]][/database]/<model>[/id]
- username nor password should be define in the url for security purpose. - the server:port should always mandatory otherwise I don't see where the client should connect. - I don't see the usage of protocol as it is the client that should select which protocol it wants to use. I think we should think about more powerfull URI scheme (perhaps REST-like) to be able to get domain/context inside. The best should be to be able to encode any of the ir.action. > Enabling it on various platforms: > > Seems it is done like so under Gnome, and then there must be some internal > method to listen for events. > gconftool-2 -s /desktop/gnome/url-handlers/foo/command '/path/to/app %s' > --type String > gconftool-2 -s /desktop/gnome/url-handlers/foo/enabled --type Boolean true > > Under MacOS, some magic is added to the Application Bundle's Info.plist, and > then the application must listen for events. > > Under Windows, find an example here: > http://blogs.msdn.com/b/noahc/archive/2006/10/19/register-a-custom-url-protocol-handler.aspx In fact I think we should allow the client to accept an url as argument and he will open a new one if there is no running one or if the runnings are not connected to the same server and database. > Challenges: > > As Tobias brought up, there are occasions where a client might need to > connect to multiple databases. The client is not currently architected to > support that. A specific example of this use case would be a "Tryton > Certified" accountant. The accountant might be retained by many clients, and > need to occasionally work with multiple tryton instances at once. I don't think. Tryton migrates easily so there is no reason to have this issue. > This brings up yet one more challenge, which is protocol compatibility. In > the accountant example, there could be an instance where one of the > accountant's clients is running a 1.X version, where another is running a 2.X > version. Backwards compatibility in the client would be needed. > > I would certainly appreciate feedback and discussions, which I will aggregate > into a blueprint. I'm against this because it slow down the development and it makes testing become an exponential task. -- Cédric Krier B2CK SPRL Rue de Rotterdam, 4 4000 Liège Belgium Tel: +32 472 54 46 59 Email/Jabber: [email protected] Website: http://www.b2ck.com/
pgplUasiFmfVN.pgp
Description: PGP signature
