Hi, for me it is a good idea to have an URL to call the client. Another use case for this is generating and maintaining automated screen shots in all provided languages for localized modules documentation.
And another feature could be form filling via url: tryton://server/database/party.party/?action=create;name=Udo; For security reasons I would allow create, write and delete from url only with user authentication, even if the user is already authenticated. On 25.08.2010, 23:02 +0200, Cédric Krier wrote: > 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. Since it is an URL which is handled by the client and the Tryton client 'speaks' netrpc only, I also can not see why it needed to handle other protocols. > > > 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. Here it could be helpful to examine the rpc requests from the client. There is to see, how the client talks to trytond in different action types. > > 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. The webdav reporting has the problem that it can only print reports which needs no user interaction. It is not able to print reports when there is a wizard which needs manual input. But to write a syntax for wizards with multiple stages/steps in an URL sounds hard. > > >> 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) Sounds like what google chromium browser does with its tabs. Handle each tab in a single process and mother process which control the tab rocesses. Good idea, but imho needs a redesign of bigger parts in the client api. For me it is not an important task in the client for now. > > >> 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 Yes, of course could be a far-away goal. For me the best and most needed stability is the actually provided migration path from server version to version. Next stabilization is to have a good framework API which provides a deprecation process, when the changes becomes rarely. But this all will take time. Cheers -- Udo Spallek ------------------------------------ virtual things Preisler & Spallek GbR Munich - Aix-la-Chapelle Windeckstr. 77 81375 Munich - Germany Tel: +49 (89) 710 481 55 Fax: +49 (89) 710 481 56 [email protected] http://www.virtual-things.biz -- [email protected] mailing list
