IPC on MeeGo

[Boudewijn Rempt]

I'm looking into writing a kind of server daemon that would generate images for several client apps. I was wondering whether there's any policy for the ipc: use dbus (even though I'd be sending mostly just image data), or do something homegrown?

[Ivan Frade]

Hi,

If your architecture is something like "request image, receive a
message with the path of the result", then DBus is OK. Do not use dbus
to transfer binary blobs, that is not good; and try to group your
requests in batches.

Somehow server creating images for multiple clients reminds me
tumbler and our thumbnailing architecture. Maybe they can give you
some inspiration.

Regards,

Ivan

Post by Boudewijn Rempt
I'm looking into writing a kind of server daemon that would generate images for several client apps. I was wondering whether there's any policy for the ipc: use dbus (even though I'd be sending mostly just image data), or do something homegrown?
--
Boudewijn Rempt | http://www.valdyas.org, http://www.krita.org
_______________________________________________
MeeGo-sdk mailing list
http://lists.meego.com/listinfo/meego-sdk
http://wiki.meego.com/Mailing_list_guidelines
http://meego.com/developers

[Boudewijn Rempt]

Post by Ivan Frade
Hi,
If your architecture is something like "request image, receive a
message with the path of the result", then DBus is OK. Do not use dbus
to transfer binary blobs, that is not good; and try to group your
requests in batches.

Hm... But we wouldn't want to store the images on disk as temp files, right? Especially if the disk is flash, that would be bad for the longevity of the disk.

Post by Ivan Frade
Somehow server creating images for multiple clients reminds me
tumbler and our thumbnailing architecture. Maybe they can give you
some inspiration.

I'll check that out.

[Boudewijn Rempt]

Post by Boudewijn Rempt

Post by Ivan Frade
Hi,
If your architecture is something like "request image, receive a
message with the path of the result", then DBus is OK. Do not use dbus
to transfer binary blobs, that is not good; and try to group your
requests in batches.

Hm... But we wouldn't want to store the images on disk as temp files, right? Especially if the disk is flash, that would be bad for the longevity of the disk.

Post by Ivan Frade
Somehow server creating images for multiple clients reminds me
tumbler and our thumbnailing architecture. Maybe they can give you
some inspiration.

I'll check that out.

I've also seen the suggestion to not use dbus but use 0MQ (http://www.zeromq.org) for the whole communication thing -- but I'm not sure whether dbus is actually the mandatory way to go in MeeGo.

[Sivan Greenberg]

I would use an HTTP server , a key value store and access it as such.
blobs seem to be enough data to justify the sockets etc...if you want
to make it part of the standard DBus interface that's something else..

-Sivan

Post by Boudewijn Rempt

Post by Boudewijn Rempt

Hi,
 If your architecture is something like "request image, receive a
message with the path of the result", then DBus is OK. Do not use dbus
to transfer binary blobs, that is not good; and try to group your
requests in batches.

Hm... But we wouldn't want to store the images on disk as temp files, right? Especially if the disk is flash, that would be bad for the longevity of the disk.

 Somehow server creating images for multiple clients reminds me
tumbler and our thumbnailing architecture. Maybe they can give you
some inspiration.

I'll check that out.

I've also seen the suggestion to not use dbus but use 0MQ (http://www.zeromq.org) for the whole communication thing -- but I'm not sure whether dbus is actually the mandatory way to go in MeeGo.
--
Boudewijn Rempt | http://www.valdyas.org, http://www.krita.org
_______________________________________________
MeeGo-sdk mailing list
http://lists.meego.com/listinfo/meego-sdk
http://wiki.meego.com/Mailing_list_guidelines
http://meego.com/developers

[Ivan Frade]

Hi,

Take also into account that DBus gives you "autoactivation" of the
server process when needed.

Regards,

Ivan

Post by Sivan Greenberg
I would use an HTTP server , a key value store and access it as such.
blobs seem to be enough data to justify the sockets etc...if you want
to make it part of the standard DBus interface that's something else..
-Sivan

Post by Boudewijn Rempt

Post by Boudewijn Rempt

Hi,
 If your architecture is something like "request image, receive a
message with the path of the result", then DBus is OK. Do not use dbus
to transfer binary blobs, that is not good; and try to group your
requests in batches.

Hm... But we wouldn't want to store the images on disk as temp files, right? Especially if the disk is flash, that would be bad for the longevity of the disk.

 Somehow server creating images for multiple clients reminds me
tumbler and our thumbnailing architecture. Maybe they can give you
some inspiration.

I'll check that out.

I've also seen the suggestion to not use dbus but use 0MQ (http://www.zeromq.org) for the whole communication thing -- but I'm not sure whether dbus is actually the mandatory way to go in MeeGo.
--
Boudewijn Rempt | http://www.valdyas.org, http://www.krita.org
_______________________________________________
MeeGo-sdk mailing list
http://lists.meego.com/listinfo/meego-sdk
http://wiki.meego.com/Mailing_list_guidelines
http://meego.com/developers

_______________________________________________
MeeGo-sdk mailing list
http://lists.meego.com/listinfo/meego-sdk
http://wiki.meego.com/Mailing_list_guidelines
http://meego.com/developers

[Sivan Greenberg]

Post by Ivan Frade
Hi,
Take also into account that DBus gives you "autoactivation" of the
server process when needed.

This accounts for quite a slow client apps start ups on Maemo when dbus
server crashes or when he service takes long time to load. I think this also
contributed to the very slow from-boot-to-dial, albeit could save memory and
battery if the services drops down after the request.

-Sivan

[Thiago Macieira]

Post by Sivan Greenberg
This accounts for quite a slow client apps start ups on Maemo when dbus
server crashes or when he service takes long time to load. I think this also

The D-Bus server should never crash. Don't plan around that: if it crashes,
it's a serious issue that needs to be solved there.

[Ville M. Vainio]

Post by Boudewijn Rempt
I'm looking into writing a kind of server daemon that would generate images for several client apps. I was wondering whether there's any policy for the ipc: use dbus (even though I'd be sending mostly just image data), or do something homegrown?

Some options:

1. Use dbus + file descriptor passing to stream the image data
2. Custom solution using shared memory.

[Sivan Greenberg]

Post by Boudewijn Rempt

Post by Boudewijn Rempt
I'm looking into writing a kind of server daemon that would generate

images for several client apps. I was wondering whether there's any policy
for the ipc: use dbus (even though I'd be sending mostly just image data),
or do something homegrown?
1. Use dbus + file descriptor passing to stream the image data
2. Custom solution using shared memory.

I would take 2. :-)

-Sivan

Post by Boudewijn Rempt
_______________________________________________
MeeGo-sdk mailing list
http://lists.meego.com/listinfo/meego-sdk
http://wiki.meego.com/Mailing_list_guidelines
http://meego.com/developers