On Apr 2, 2009, at 8:37 AM, Glimmer Labs wrote:

Pardon my enthusiasm for the DBus idea. What I meant by "extended goal" is that I would first design, implement (a subset of), and test the API. Then, time permitting, I would add the DBus functionality that would bring the system to a reasonably usable state.

Oh, no problem. You're in some good company with your enthusiasm.

As far as Guile, Swig, etc. I believe that DBus gives us most of that since it is inter process communication and it doesn't really matter what is on the other end (say, a Python program or script.) Regardless, I believe that dealing with language bindings and linkings (however we decide to manage them) would be an extension to this summers project, otherwise it would be easy to bite off more than I could chew. For now I will leave that up to the users of the API.

Yes. I think language bindings could be a later step.

First would be to figure out the *logical* objects involved, aspects, attributes, functionality, etc.

Then could come how to access those object and methods in a high level "API".

Then that API could be mapped to several transports, DBus being among them.

And finally other people can add language bindings on various sides of transports.

I am very intrigued by the concept of using XForms. On one hand they seem like a potentially elegant solution. On the other hand, whether or not they could or should be used this way, they certainly are not usually used this way. Given the moderate information I was able to dig up about them I'm not sure that XForms would be the best choice for a student project, which should be on fairly solid ground in terms of probability of success.

Does anyone who has experience with XForms (or discussed it) have any advice about the feasibility of using them for a relatively short project?

Well... I've done shipping hand-held apps with it, so am pretty comfortable with the scope.

XForms is not really a new thing in and of itself. Instead it is how to use existing technologies to achieve a nice effect.

First of all it is built on top of DOM. So you need to have a document object model. One good aspect is that SVG already has DOM bindings, etc.

Then you get to point at things in such a tree via XPath

Then toss in DOM Events to get interactivity, change notifications, etc.

*Then* you can glue things up to actual UI widgets. One interesting point is that the current extension mechanism allows for parameters in declarative XML form, in line with how XPath sets things up.

So in the case of the existing UI, we have the external final part done, but not all the middle parts. For an SoC project one could do the same thing. That is, pick some subsets of immediate functionality, and just implement it in such a way so that later changes can bring in full DOM interaction, etc.

If nothing else, reading through XForms Essentials can help with various concepts that can map into other areas also. Again, since it uses standard things like DOM, DOM Events and XPath, one can gain insights for any applications of those.