Custom URLs
Phillip Heller
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[:password]@]server[:port][/protocol]][/database]/<model>[/id]
Examples:
tryton://sale.order
tryton://party.party/123
tryton://server/party.contact/456
tryton://localhost/netrpc/mycompany/sale.order/12345
tryton://jeff:sUpErSeCrEt!@tryton.some.tld:9999/xmlrpc/acme/support.case/4789
tryton://readonly@tryton/xmlrpc/bugtracker/bug.history/27891
Some use cases would be:
Embed them in email, as part of a workflow. When an employ submits an expense report, the workflow goes to a manager approval state. A request is created for the employee's manager, with content of "An expense report has been submitted for your approval. Please view it here: tryton://trytonhost/expense.report/789"
Open them via an external system. When a customer calls into a call center to inquire about an invoice, an IVR (Interactive Voice Reponse) system asks them for their Invoice Number, and then the numeric passcode associated with the billing party record. These values are validated and then the IVR transfers their call to an agent, and transmits "tryton://invoice.invoice/1234" to an helper application running on the agent's machine, which invokes the appropriate operating system action to open this URL.
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
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.
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.
Regards,
Phil
Cédric Krier
> 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[:password]@]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: cedric...@b2ck.com
Website: http://www.b2ck.com/
Phillip Heller
On Aug 25, 2010, at 3:28 PM, Cédric Krier wrote:
> 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[:password]@]server[:port][/protocol]][/database]/<model>[/id]
>
> - username nor password should be define in the url for security purpose.
I generally agree. Thought it might be useful for readonly access.
> - the server:port should always mandatory otherwise I don't see where the
> client should connect.
The thought here was that some reasonable defaults would be assumed. If port is not specified, but protocol is, then choose the default port for that protocol. If server isn't specified, then use any connected server. Though this would not work if there were multiple servers open (when the client can do this).
I thought the same idea with the database.
Though I do now agree that server and database are mandatory. Protocol and port can both default to something, and optionally be overriden.
>
> - 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 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? 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.
> 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.
I agree that invoking the application with a URL should, if the client is already running, signal to it that a new window should be opened with the URL. And, if the client is not already running, it should be started, and a window opened with the URL.
>> 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.
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. :-)
Regards,
Phil
Cédric Krier
> > - 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.
Udo Spallek
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
in...@virtual-things.biz
http://www.virtual-things.biz
Hartmut Goebel
> tryton:/[/[username[:password]@]server[:port][/protocol]][/database]/<model>[/id]
IMHO the "protocol" part contradicts the URL logic, where the first part
(the "schema") defined the protocol. `RFC 1630`__ is not really clear
about this, but section "Specific Schemes" supports this. It's also
custom usage to use the schem to denote the protocol.
BTW: THe official `IANA URI-Schema listing`__ contains somthing
interesting like "iris.xpc".
__http://tools.ietf.org/html/rfc1630
__http://www.iana.org/assignments/uri-schemes.html
--
Schönen Gruß - Regards
Hartmut Goebel
Dipl.-Informatiker (univ.), CISSP, CSSLP
Goebel Consult
Spezialist für IT-Sicherheit in komplexen Umgebungen
http://www.goebel-consult.de
Monatliche Kolumne: http://www.cissp-gefluester.de/
Goebel Consult mit Mitglied bei http://www.7-it.de
Cédric Krier
> On 25/08/10 16:08 -0400, Phillip Heller wrote:
> > > 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.
Perhaps simple use parameters with value encoded in JSON.
like tryton://..../party.party?domain=[['name', '=', 'Bob']];context={'language': 'en_US'}
Tobias Paepke
> On 25/08/10 23:02 +0200, C�dric Krier wrote:
>> On 25/08/10 16:08 -0400, Phillip Heller wrote:
>>>> 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.
> Perhaps simple use parameters with value encoded in JSON.
>
> like tryton://..../party.party?domain=[['name', '=', 'Bob']];context={'language': 'en_US'}
>
if used in for example in emails it would lead to a really long and ugly
url which could break on end of line.
what about kind of shortening service inside tryton? like:
tryton://.../Voh7eel6hoa3coo8faehahgoh5uijoh3
an rpc call could generate it for external services.
maybe we could pack that whole stuff into a base64 encoded string.
but nevertheless there exists a maximum length of urls in several
browsers, maybe mail clients, too.
I don't know if its a problem if external handlers would be triggered
like in this case.
just my 2c
tobias
Sharoon Thomas
I like the idea of JSON and the shortening too.
A combination of both should do i guess. And probably the RPC service could be one which does not need authentication like the database listing webservice.
Thanks,
Sharoon Thomas
On 27 Aug 2010, at 11:40, Tobias Paepke wrote:
> On 27.08.2010 12:26, Cédric Krier wrote:
> --
> tryto...@googlegroups.com mailing list
Hartmut Goebel
> if used in for example in emails it would lead to a really long and ugly
> url which could break on end of line.
One should enclose URL in <...> anyway :-)
> maybe we could pack that whole stuff into a base64 encoded string.
This would only increase the length of the URL, so no benefit here.
But what about compressing the data first? But this is is only of use,
starting at a certain length.
Cédric Krier
> On 27.08.2010 12:26, Cédric Krier wrote:
> > On 25/08/10 23:02 +0200, Cédric Krier wrote:
> >> On 25/08/10 16:08 -0400, Phillip Heller wrote:
> >>>> 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.
> > Perhaps simple use parameters with value encoded in JSON.
> >
> > like tryton://..../party.party?domain=[['name', '=', 'Bob']];context={'language': 'en_US'}
> >
> I like the idea of JSON
>
> if used in for example in emails it would lead to a really long and ugly
> url which could break on end of line.
I don't think it will be very long. Domain are a way to express shorter a list
of ids. And context will not growth.
> what about kind of shortening service inside tryton? like:
> tryton://.../Voh7eel6hoa3coo8faehahgoh5uijoh3
>
> an rpc call could generate it for external services.
This will create a centralized point which will bring some difficulties who
will maintain it.