Tip:
Highlight text to annotate it
X
Welcome to another short introduction of the XBUP Project.
This presentation will be about service architecture and focus on modularity.
There will be also some simple example of application
using underlying service for some common tasks.
This project should not produce just the protocol,
but also provide appropriate service to match it.
This service should be available for the wide range
of operating systems and architectures.
It should consist of exchangeable modules
possibly managed by package management system.
The service should provide catalog functionality and
allow both local execution and remote invocation.
As you can see on this simple diagram,
service should be build on top of database
and repository of modules providing further functionality.
It shouldn't hide all the core functionality
of the operating system thou.
Support for modularity should bring possibility
to update service when needed
by simply downloading modules as needed
while preserving as much functionality as possible.
With various interfaces users should be able to view and enter
new types of values as for example using editor modules
for single line entry or more complex panels or dialog editors.
There should be also modules providing conversions
such as transforming data among various formats
or for backward compatibility.
This should be all working automatically,
but user should have control to replace or bypass any module
as for his own priorities or preferences.
For basic general calls, XBUP protocol itself should be used,
but whenever possible more optimized binary data formats
should be used instead if available.
Each module should run in it's own separated sand box
so no undesired risk should emerge.
Service should be able to process many requests at the same time,
in best case resulting into possibility of constructing
something like computational grid or service cloud.
As for example application, intent is to shift
as many functionality as possible onto the service
to have small application which could be simply extended
by adding more modules to the system.
Service should provide conversion between various input formats.
In the best case application should consist of modules itself
to provide it's own functionality to other applications.
First example is trying to outline how automatic format conversion
should work, requesting specific type of data.
Conversion itself should be handled by service.
The other example shows how the file properties dialog
could be opened using the service.
Application here can show it's additional properties tabs,
but service could for example add another tab with EXIF data
if source file is JPEG file.
That concludes this short presentation.
It aimed to show, that
this project should provide service for the protocol itself
while also providing various capabilities
like modularity and remote calling
from world of big enterprise applications.
Thank you for your time and if you still want more information,
please visit project's website.