High hopes for Unite, but depressed by implementation

I had high hopes for Unite as a platform for not only delivering static content, but services too. Unfortunately, looking at the documentation and creating a simple application it now seems too limiting.

When you compare Unite with the POW Firefox extension there are similarities and a big difference. POW includes SQL Lite, an embedded SQL database and Unite doesn't. That means everything has to be file based without the possibility of using a data model for your content. Sure you can probably create XML files and transform them on the fly, but having a structured data store with indexing opens up possibilities. I can understand Opera wanting to make things simple for users, but not including an embedded SQL database like H2 or SQL Lite is limiting for developers. I do realize that a widget can use XML-HTTP requests to HTTP endpoints either on the web or located at localhost, but 1) I wouldn't want to make my SOLR installation open to the Web for security reason, and 2) using localhost has downsides since it has implications on widget distribution.

While Unite can serve dynamic content and includes a template engine, markuper, it too is limiting. The documentation says it uses the DOM, probably a good thing, but it has a downside. Take perfectly good XHTML, run it through markuper and out pops invalid XHTML. Further, markuper uses special data* attributes for dynamic content. I'm surprised at Opera for not realizing that adding non-namespaced attributes to XHTML does not follow the standard. Worst, these attributes seem to be retained after the transformation, so they get sent to your user agents downstream. Not acceptable.

I created a simple widget that hooked _index and returned an HTTP 404 status, then I looked at the response with fiddler an HTTP debugging proxy tool. The response is not quite up to spec. The Server header contains "Opera/..." where ... is the DNS proxy name to your service, e.g., work.user.operaunite.com. The contents "Opera/work.user.operaunite.com" isn't a valid DNS name and is sure to break user agents downstream that are expecting a valid DNS name for the contents of the Server header. The response also contains an entity with the contents of an HTML document that has an H1 with "404 Not Found" and the text " Resource not found". OK, my first attempt here, I didn't do a response.write so the Unite runtime probably added a default entity. Wrong, I added a response.write('') and reloaded and reran the widget. Same result. So I changed the response.write to response.write('foobar'). Still the same result. It appears that you cannot change the entity body on non-200 HTTP status codes. According to the HTTP spec I should be able to add an entity body to almost all status codes except when explicitly stated. Again not good for developers and Opera not paying attention to standards. While I have not tried it yet, but after reading the documentation, it doesn't appear to me that you can generate multipart MIME entities for your response.

While using Fiddler to see what was being sent over HTTP, I noticed that Unite periodically calls a pseudo service for checking activity, e.g., /{servicename}/activity?q=#. This might be OK for serving static content, but as a developer who would like to create services this is unacceptable. I cannot have service endpoints poping up that I don't have any control over. There should be some way to configure Unite to not access any special endpoints, better yet I think Unite should have created a special endpoint under their own {servicename} that queried itself for activity, rather than injecting it into your {servicename} namespace, e.g., /unite/activity?s={servicename}&q=#.

I guess Unite has a little different vision.

However, in case running a local server, apache for example. Interesting if it would be possible for Unite to link to localhost. For example if someone accesses my file whatever?foo=bar it would be forwarded to my localhost counterpart and so a visitor will be served with what my apache server outputs. Or communicate with Apache some other way.

It needs a database of some sort, flat files will do for me! I'm not very good with this JavaScript thing, I am a novice programmer and do all my stuff in Perl. The current method I'm using with Opera Unite is append data to a variable, rather than a file. So if Opera Unite disconnects for some reason, as it usually does, all the data is gone!

Edit: I actually found a way to use a database, that way, even if I turn off the service and turn it back on, all the data will still be there. Here is an example that helped me a lot: http://unitehowto.com/CRUD_and_static This website is very helpful overall.

Post edited Thursday, 18. June 2009, 09:02:14