It would be cool, if TinyTM had an extensibility framework, similar to Firefox extensions or Eclipe plug-ins. It would allow for adding ecapsulated, well-defined functionality in a flexible manner. I am thinking about functionality such as file filters, packaged in easlily installable modules.
I am not sure, what is involved in creating such a framework. I had a look Firefox extensions and they work a lot with XML config files that pulled in at runtime.
Any thoughts?
Cheers,
Martin
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Great point, such a modular plug & play approach would allow developers to extend the base product with little effort.
I believe that there is nothing on the technical side at the moment that would impede such an architecture. However, with a client-server architecture, we'd have to face extensions on three different levels:
Let's use the example of a specific terminology component that a user wants to add:
- Server:
The PostgreSQL data model would need an extension to hold the terminology data
- Protocol:
The server would need to offer several new "protocol" calls. Currently these are Pl/SQL procedures, but in the future we'd have to extend a web-service protocol as well...
- Client:
The client would need to be able to load plugins and execute them. This could actually be similar to how Firefox does it.
So yeah, let's do it!
The current V0.1 (and probably the next V0.2 version) are still so "tiny" that a plugin architecture would be bigger then the entire code of the rest of the TM, but yeah, let's include this plugin architecture as soon as feasible.
Cheers!
Frank
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I guess the component that requires the most centralised control is the protocol, since this is the interface between all server and client implementations. However, the client could be pretty open to this modular approach. Could we just take Eclipse, rip out all the non-required plugins, and turn it into an extensible translation editing client? That way, there would be no need to reinvent or recode the plugin architecture.
Cheers,
Martin
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi all,
It would be cool, if TinyTM had an extensibility framework, similar to Firefox extensions or Eclipe plug-ins. It would allow for adding ecapsulated, well-defined functionality in a flexible manner. I am thinking about functionality such as file filters, packaged in easlily installable modules.
I am not sure, what is involved in creating such a framework. I had a look Firefox extensions and they work a lot with XML config files that pulled in at runtime.
Any thoughts?
Cheers,
Martin
Hi Martin,
Great point, such a modular plug & play approach would allow developers to extend the base product with little effort.
I believe that there is nothing on the technical side at the moment that would impede such an architecture. However, with a client-server architecture, we'd have to face extensions on three different levels:
Let's use the example of a specific terminology component that a user wants to add:
- Server:
The PostgreSQL data model would need an extension to hold the terminology data
- Protocol:
The server would need to offer several new "protocol" calls. Currently these are Pl/SQL procedures, but in the future we'd have to extend a web-service protocol as well...
- Client:
The client would need to be able to load plugins and execute them. This could actually be similar to how Firefox does it.
So yeah, let's do it!
The current V0.1 (and probably the next V0.2 version) are still so "tiny" that a plugin architecture would be bigger then the entire code of the rest of the TM, but yeah, let's include this plugin architecture as soon as feasible.
Cheers!
Frank
Hi Frank,
I guess the component that requires the most centralised control is the protocol, since this is the interface between all server and client implementations. However, the client could be pretty open to this modular approach. Could we just take Eclipse, rip out all the non-required plugins, and turn it into an extensible translation editing client? That way, there would be no need to reinvent or recode the plugin architecture.
Cheers,
Martin
That should be no problem...
Would you like to do this? :-)
Cheers,
Frank