On 25/08/10 16:08 -0400, Phillip Heller wrote: > > - I don't see the usage of protocol as it is the client that should select > > which protocol it wants to use. > > I can imagine one use case where the client specifying the protocol is > important; perhaps when an employee is first hired and then created in > tryton. The final action of the workflow is to send the user an email that > says: > > "Your tryton account has been created, access it here: > tryton://server/netrpc/database".
I don't understand why the protocol is required. > > > 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. > > Can you give some examples of how you might encode context variables or > invoke other actions? No I don't have. > I think context is most useful in the query string: > > tryton://server/database/sale.order/123?lang=es_ES > > A good thing to work out would be how to run and render a report via URI. I > can see the usefulness in pulling an invoice this way - especially if this > URL method can eventually be ported to the web client. It is already the case with WebDAV. > >> 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. > > Hmmh, I'm not sure I understand your response here. > > To further explain my point: > > Perhaps the Accountant is researching an accounting mismatch at > tryton://companyA/database, and he has many windows open, with search > results. Then, the accountant gets a call from companyB saying "we need > emergency help". He should be able to do "Window" -> "New", and connect to > companyB's tryton instance. Just run an other Tryton client. > > Similarly, if he gets two emails, with URLs that specify different tryton > instances, new windows should be created for each. (rather than running > multiple instances of the whole application) > > > > >> 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. > > Well, it really only becomes a concern when there are many more instances of > Tryton running in the real world. So it really isn't important to discuss > now anyways. :-) No it is not linked to the number of instances. -- 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/
pgpRIgm7Ivfvp.pgp
Description: PGP signature
