Comments on: Atomato

By: Johan Segolsson

Johan Segolsson — Tue, 30 Nov 1999 00:00:00 +0000

How about using wsdl files to describe the methods, don’t know if it’s possible to descibe a DBUS method/service but if Atomato at least supports them it would be an easy way to ‘drop in’ support for webservices.

By: Rodrigo Moya

Rodrigo Moya — Tue, 30 Nov 1999 00:00:00 +0000

Yeah, using WSDL (or something similar) is the idea, so yeah, WSDL might be the correct thing to use, although it might get things too complicate. I’ll have a look

By: AC

AC — Tue, 30 Nov 1999 00:00:00 +0000

KDE has a SoC projects about this as well, called “workflow”. Maybe it would be nice if there was some kind of compatibility between the two.

By: Nelson

Nelson — Tue, 30 Nov 1999 00:00:00 +0000

Hi, a really promising and needed project, some random concerns/ideas/delirious :

* It seems very difficult to connect (pipe) the different actions on the workflow, I suppose you would define some types of input and output data like (FILE,URI,NUMBER,TEXT) and the gui would allow to connect the actions according to the types that the action supports, like an epiphany action that takes an URI and download it to a FILE, and connects to a ftp action that takes the FILE and a URI where to upload that file…

* Also in the case of actions that are scripts with multiple commands, who would check for the existence of those commands, the own action incorporating m4 files, or by centralizing all these actions in one package that checks for all commands on the configure…

* Apart from the above issues that are atomato related, just the applications begining to export their abilities as dbus methods would open lot of possibilities, e.g. gimp export a dbus method that takes an image and returns that image with the red-eye effect corrected, then I could cook up a python script to upload images to my www gallery that would red-eye correct them if this gimp dbus method is present.

* Also I think before all applications begin to export dbus methods in an arbitrary way, there should be a freedesktop naming policy that defines common methods in an object like (open,save,close) and common objects like IMAGE,SONG,MOVIE,DOCUMENT,CONTACT,ARCHIVER or BROWSER, so calling BROWSER->download_url($url); would result in that method executed by epiphany in GNOME and konqueror in KDE, as both registered for that fd.o defined method. Other standard calls could be ARCHIVER->zip($files) or CONTACT->is_online($name), IMAGE->resize_image($image) , that would be done by the applications that registered for them.

By: Christian

Christian — Tue, 30 Nov 1999 00:00:00 +0000

What about using RDF/OWL documents like I've done in S-Flux? Schemas are described at http://sflux.sourceforge.net/schema.php

By: GrumZ

GrumZ — Tue, 30 Nov 1999 00:00:00 +0000

Great news !

If I understand well, the aTomato scripts created by the user, will be exported to DBUS too, so other applications can list and activate them too. I'm of course thinking about integrating it in Nautilus-actions[1] once it will be ready ;o)

First, I have to document myself about DBUS...

[1] http://www.grumz.net/taxonomy/term/2/9

By: Christian

Christian — Tue, 30 Nov 1999 00:00:00 +0000

I’ve quickly looked at Atomao code and it seems to me it lacks of a couple of features that instead are present in S-Flux:
1) There’s no mimetype->operation association. This means you can’t filter out the operations suitable for a document. Probably we can go beyond the simple link mimetype->operation extending it to other kinds of objects (devices or so). All we have to do is to provide a URI to every object (maybe they already exists, I don’t know…sorry).
2) In my opinion only DBUS in not enough. I mean probably giving the opportunity to expose to atomato command line applications too could be really useful. Linux systems are plenty of excellent command line utilities and letting newbies users a simple way to use them could be a great thing.

Do you agree?