fsoraw, a wrapper launcher with FSO resource preallocation

[Nicola Mfb]

I wrote a little c tool for launching programs preallocating FSO resources.
I'm using it to prevent fso dimming/suspending while tangogps is
running without change/reset shr settings.
To achieve this modify the Exec line in
/usr/share/applications/tangogps.desktop in:

Exec=fsoraw -r CPU,Display tangogps

sources at http://noko.svn.sourceforge.net/viewvc/noko/trunk/fsoraw
there is a rude bitbake recipie too.

Suggestion and bugs are welcome (if someone interested).

regards

      Nicola

_______________________________________________
Shr-devel mailing list
[hidden email]
http://lists.projects.openmoko.org/mailman/listinfo/shr-devel

[Tom-6]

Thanks a lot, I'm glad someone finally did it!
A few suggestions:
I think adding a special flag for every common resource is a good idea, i.e:
'fsoraw --cpu --display APP' or even 'fsoraw -c -d APP' for quick cli usage.
is more elegant in my opinion, don't you agree?
And I also think -f should be on by default, afterall it'll be used "behind the scenes" and normal users would want the app to run even if not possible to ask for the cpu... just my opinion though.

Thanks,
Tom.

On Tue, Apr 14, 2009 at 5:27 AM, Nicola Mfb <[hidden email]> wrote:

I wrote a little c tool for launching programs preallocating FSO resources.
I'm using it to prevent fso dimming/suspending while tangogps is
running without change/reset shr settings.
To achieve this modify the Exec line in
/usr/share/applications/tangogps.desktop in:

Exec=fsoraw -r CPU,Display tangogps

sources at http://noko.svn.sourceforge.net/viewvc/noko/trunk/fsoraw
there is a rude bitbake recipie too.

Suggestion and bugs are welcome (if someone interested).

regards

     Nicola

_______________________________________________
Shr-devel mailing list
[hidden email]
http://lists.projects.openmoko.org/mailman/listinfo/shr-devel

_______________________________________________
Shr-devel mailing list
[hidden email]
http://lists.projects.openmoko.org/mailman/listinfo/shr-devel

[William Kenworthy]

Is there any advantage using this over a simple shell script using mdbus
calls?

BillK

On Tue, 2009-04-14 at 12:20 +0300, Tom wrote:

> Thanks a lot, I'm glad someone finally did it!
> A few suggestions:
> I think adding a special flag for every common resource is a good
> idea, i.e:
> 'fsoraw --cpu --display APP' or even 'fsoraw -c -d APP' for quick cli
> usage.
> is more elegant in my opinion, don't you agree?
> And I also think -f should be on by default, afterall it'll be used
> "behind the scenes" and normal users would want the app to run even if
> not possible to ask for the cpu... just my opinion though.
>
> Thanks,
> Tom.
>
>
> On Tue, Apr 14, 2009 at 5:27 AM, Nicola Mfb <[hidden email]>
> wrote:
>         I wrote a little c tool for launching programs preallocating
>         FSO resources.
>         I'm using it to prevent fso dimming/suspending while tangogps
>         is
>         running without change/reset shr settings.
>         To achieve this modify the Exec line in
>         /usr/share/applications/tangogps.desktop in:
>        
>         Exec=fsoraw -r CPU,Display tangogps
>        
>         sources at
>         http://noko.svn.sourceforge.net/viewvc/noko/trunk/fsoraw
>         there is a rude bitbake recipie too.
>        
>         Suggestion and bugs are welcome (if someone interested).
>        
>         regards
>        
>              Nicola
>        
>         _______________________________________________
>         Shr-devel mailing list
>         [hidden email]
>         http://lists.projects.openmoko.org/mailman/listinfo/shr-devel
>
>
> _______________________________________________
> Shr-devel mailing list
> [hidden email]
> http://lists.projects.openmoko.org/mailman/listinfo/shr-devel

--
William Kenworthy <[hidden email]>
Home in Perth!


_______________________________________________
Shr-devel mailing list
[hidden email]
http://lists.projects.openmoko.org/mailman/listinfo/shr-devel

[kimaidou]

Hi
This is intersting too : can you send an example of such a script ?

And how do you use it ? By changing the desktop icon exe,  like "myscript && tangogps" instead of "tangogps" ?
Thanks in advance

2009/4/14 William Kenworthy <[hidden email]>

Is there any advantage using this over a simple shell script using mdbus
calls?

_______________________________________________
Shr-devel mailing list
[hidden email]
http://lists.projects.openmoko.org/mailman/listinfo/shr-devel

[Tom-6]

There are a couple of major advantages in using this app over a script, the first:
with this app it'll work, with a script with mdbus calls it won't. ;]
When the app that requests the resource closes, the framework automatically releases it, so when you call mdbus request, the resource is requested, though then mdbus exists and the resource is freed, with this app it shouldn't happen (not sure how it wrote it, though that's why an app is needed in the first place, just a simple dbus call and a system() call.
Second of all, mdbus takes a couple of seconds to start, so 2 consequtive call to mdbus make apps terribly slow to launch, this app shouldn't have any impact.

Tom.

On Tue, Apr 14, 2009 at 12:35 PM, William Kenworthy <[hidden email]> wrote:

Is there any advantage using this over a simple shell script using mdbus
calls?

BillK

On Tue, 2009-04-14 at 12:20 +0300, Tom wrote:
> Thanks a lot, I'm glad someone finally did it!
> A few suggestions:
> I think adding a special flag for every common resource is a good
> idea, i.e:
> 'fsoraw --cpu --display APP' or even 'fsoraw -c -d APP' for quick cli
> usage.
> is more elegant in my opinion, don't you agree?
> And I also think -f should be on by default, afterall it'll be used
> "behind the scenes" and normal users would want the app to run even if
> not possible to ask for the cpu... just my opinion though.
>
> Thanks,
> Tom.
>
>
> On Tue, Apr 14, 2009 at 5:27 AM, Nicola Mfb <[hidden email]>
> wrote:
>         I wrote a little c tool for launching programs preallocating
>         FSO resources.
>         I'm using it to prevent fso dimming/suspending while tangogps
>         is
>         running without change/reset shr settings.
>         To achieve this modify the Exec line in
>         /usr/share/applications/tangogps.desktop in:
>
>         Exec=fsoraw -r CPU,Display tangogps
>
>         sources at
>         http://noko.svn.sourceforge.net/viewvc/noko/trunk/fsoraw
>         there is a rude bitbake recipie too.
>
>         Suggestion and bugs are welcome (if someone interested).
>
>         regards
>
>              Nicola
>
>         _______________________________________________
>         Shr-devel mailing list
>         [hidden email]
>         http://lists.projects.openmoko.org/mailman/listinfo/shr-devel
>
>
> _______________________________________________
> Shr-devel mailing list
> [hidden email]
> http://lists.projects.openmoko.org/mailman/listinfo/shr-devel

--
William Kenworthy <[hidden email]>
Home in Perth!

_______________________________________________
Shr-devel mailing list
[hidden email]
http://lists.projects.openmoko.org/mailman/listinfo/shr-devel

[William Kenworthy]

Ive sent it the list a couple of times in the past - its actually not
mine but based a suggestion made awhile back.  Also does screen
rotation.  I just use a sepatae script for each app and comment out
lines as neccesar.  e.g., this is my "car" gps script.  When walking, I
allow the screen to blank, and dont rotate the screen.  I cant see any
advantage to a program over this script unless it can do what the script
does (including screen rotation, as you have to still run multiple
programs.  mdbus is currently slow (apparently thats being looked at) so
speed is perhaps one area it has an advantage?

#!/bin/sh

export USER='root'
export HOME='/home/root'
export PWD='/home/root'

cd /home/root

/usr/bin/xrandr -o 1

mdbus -s org.shr.ophonekitd.Usage /org/shr/ophonekitd/Usage
org.shr.ophonekitd.Usage.RequestResource 'CPU'
mdbus -s org.shr.ophonekitd.Usage /org/shr/ophonekitd/Usage
org.shr.ophonekitd.Usage.RequestResource 'Display'

/usr/bin/tangogps

mdbus -s org.shr.ophonekitd.Usage /org/shr/ophonekitd/Usage
org.shr.ophonekitd.Usage.ReleaseResource 'CPU'
mdbus -s org.shr.ophonekitd.Usage /org/shr/ophonekitd/Usage
org.shr.ophonekitd.Usage.ReleaseResource 'Display'

/usr/bin/xrandr -o 0



On Tue, 2009-04-14 at 11:52 +0200, kimaidou wrote:

> Hi
> This is intersting too : can you send an example of such a script ?
>
> And how do you use it ? By changing the desktop icon exe,  like
> "myscript && tangogps" instead of "tangogps" ?
> Thanks in advance
>
> 2009/4/14 William Kenworthy <[hidden email]>
>         Is there any advantage using this over a simple shell script
>         using mdbus
>         calls?
>

--
William Kenworthy <[hidden email]>
Home in Perth!


_______________________________________________
Shr-devel mailing list
[hidden email]
http://lists.projects.openmoko.org/mailman/listinfo/shr-devel

[William Kenworthy]

On Tue, 2009-04-14 at 13:02 +0300, Tom wrote:
> There are a couple of major advantages in using this app over a
> script, the first:
> with this app it'll work, with a script with mdbus calls it won't. ;]
mdbus calls work fine, though admittedly slowly - not sure what you
mean?

> When the app that requests the resource closes, the framework
> automatically releases it, so when you call mdbus request, the
> resource is requested, though then mdbus exists and the resource is
> freed, with this app it shouldn't happen (not sure how it wrote it,
> though that's why an app is needed in the first place, just a simple
> dbus call and a system() call.
This is an advantage to the script! - you make a call to request the
resource, and a second call to release it - its under your control when
you do it.


> Second of all, mdbus takes a couple of seconds to start, so 2
> consequtive call to mdbus make apps terribly slow to launch, this app
> shouldn't have any impact.
>
This is one area where the program should definitely help - though only
if its overhead + other commands needed such as xrandr dont add up to
more time than just the script.

> Tom.
>
> On Tue, Apr 14, 2009 at 12:35 PM, William Kenworthy
> <[hidden email]> wrote:
>         Is there any advantage using this over a simple shell script
>         using mdbus
>         calls?
>        
>         BillK
>        
>        
>         On Tue, 2009-04-14 at 12:20 +0300, Tom wrote:
>         > Thanks a lot, I'm glad someone finally did it!
>         > A few suggestions:
>         > I think adding a special flag for every common resource is a
>         good
>         > idea, i.e:
>         > 'fsoraw --cpu --display APP' or even 'fsoraw -c -d APP' for
>         quick cli
>         > usage.
>         > is more elegant in my opinion, don't you agree?
>         > And I also think -f should be on by default, afterall it'll
>         be used
>         > "behind the scenes" and normal users would want the app to
>         run even if
>         > not possible to ask for the cpu... just my opinion though.
>         >
>         > Thanks,
>         > Tom.
>         >
>         >
>         > On Tue, Apr 14, 2009 at 5:27 AM, Nicola Mfb
>         <[hidden email]>
>         > wrote:
>         >         I wrote a little c tool for launching programs
>         preallocating
>         >         FSO resources.
>         >         I'm using it to prevent fso dimming/suspending while
>         tangogps
>         >         is
>         >         running without change/reset shr settings.
>         >         To achieve this modify the Exec line in
>         >         /usr/share/applications/tangogps.desktop in:
>         >
>         >         Exec=fsoraw -r CPU,Display tangogps
>         >
>         >         sources at
>         >
>         http://noko.svn.sourceforge.net/viewvc/noko/trunk/fsoraw
>         >         there is a rude bitbake recipie too.
>         >
>         >         Suggestion and bugs are welcome (if someone
>         interested).
>         >
>         >         regards
>         >
>         >              Nicola
>         >
>         >         _______________________________________________
>         >         Shr-devel mailing list
>         >         [hidden email]
>         >
>         http://lists.projects.openmoko.org/mailman/listinfo/shr-devel
>         >
>         >
>         > _______________________________________________
>         > Shr-devel mailing list
>         > [hidden email]
>         >
>         http://lists.projects.openmoko.org/mailman/listinfo/shr-devel
>        
>         --
>         William Kenworthy <[hidden email]>
>         Home in Perth!
>        
>
>

--
William Kenworthy <[hidden email]>
Home in Perth!


_______________________________________________
Shr-devel mailing list
[hidden email]
http://lists.projects.openmoko.org/mailman/listinfo/shr-devel

[Tom-6]

It is true that you don't have to wait for mdbus to finish, though that still doesn't solve the second issue I talked about, automatic releasing of resources by the framework. The framework releases the resource once the client who asked for it (in this case mdbus) closes, so requesting a resource with mdbus doesn't really do anything.

On Tue, Apr 14, 2009 at 1:20 PM, Christophe Badoit <[hidden email]> wrote:

Tom a écrit :

> There are a couple of major advantages in using this app over a script,
> the first:
> with this app it'll work, with a script with mdbus calls it won't. ;]
> When the app that requests the resource closes, the framework
> automatically releases it, so when you call mdbus request, the resource
> is requested, though then mdbus exists and the resource is freed, with
> this app it shouldn't happen (not sure how it wrote it, though that's
> why an app is needed in the first place, just a simple dbus call and a
> system() call.
> Second of all, mdbus takes a couple of seconds to start, so 2
> consequtive call to mdbus make apps terribly slow to launch, this app
> shouldn't have any impact.

It should be possible to speed the mdbus calls, just by putting a "&"
after them ?

It doesn't matter if the dbus call is not finished before the app is
actually called.

--
Christophe Badoit

_______________________________________________
Shr-devel mailing list
[hidden email]
http://lists.projects.openmoko.org/mailman/listinfo/shr-devel

[William Kenworthy]

I think you misunderstand how mdus works - because it certainly doesnt
work like that in practise!  i.e, when you request cpu the FR doesnt
suspend, when you request display the display stays on.  When you
release the resources by a further mdbus calls, it goes back to the
prior settings.  i.e., you request a resource, its not relesed when
mdbus exits.

BillK


On Tue, 2009-04-14 at 13:32 +0300, Tom wrote:

> It is true that you don't have to wait for mdbus to finish, though
> that still doesn't solve the second issue I talked about, automatic
> releasing of resources by the framework. The framework releases the
> resource once the client who asked for it (in this case mdbus) closes,
> so requesting a resource with mdbus doesn't really do anything.
>
>
>
> On Tue, Apr 14, 2009 at 1:20 PM, Christophe Badoit
> <[hidden email]> wrote:
>         Tom a écrit :
>         > There are a couple of major advantages in using this app
>         over a script,
>         > the first:
>         > with this app it'll work, with a script with mdbus calls it
>         won't. ;]
>         > When the app that requests the resource closes, the
>         framework
>         > automatically releases it, so when you call mdbus request,
>         the resource
>         > is requested, though then mdbus exists and the resource is
>         freed, with
>         > this app it shouldn't happen (not sure how it wrote it,
>         though that's
>         > why an app is needed in the first place, just a simple dbus
>         call and a
>         > system() call.
>         > Second of all, mdbus takes a couple of seconds to start, so
>         2
>         > consequtive call to mdbus make apps terribly slow to launch,
>         this app
>         > shouldn't have any impact.
>        
>        
>         It should be possible to speed the mdbus calls, just by
>         putting a "&"
>         after them ?
>        
>         It doesn't matter if the dbus call is not finished before the
>         app is
>         actually called.
>        
>         --
>         Christophe Badoit
>        
>
>
> _______________________________________________
> Shr-devel mailing list
> [hidden email]
> http://lists.projects.openmoko.org/mailman/listinfo/shr-devel

--
William Kenworthy <[hidden email]>
Home in Perth!


_______________________________________________
Shr-devel mailing list
[hidden email]
http://lists.projects.openmoko.org/mailman/listinfo/shr-devel

[Helge Hafting]

William Kenworthy wrote:

> On Tue, 2009-04-14 at 13:02 +0300, Tom wrote:
>> There are a couple of major advantages in using this app over a
>> script, the first:
>> with this app it'll work, with a script with mdbus calls it won't. ;]
> mdbus calls work fine, though admittedly slowly - not sure what you
> mean?
>
>> When the app that requests the resource closes, the framework
>> automatically releases it, so when you call mdbus request, the
>> resource is requested, though then mdbus exists and the resource is
>> freed, with this app it shouldn't happen (not sure how it wrote it,
>> though that's why an app is needed in the first place, just a simple
>> dbus call and a system() call.
> This is an advantage to the script! - you make a call to request the
> resource, and a second call to release it - its under your control when
> you do it.
>

Assuming that the script works flawlessly. If the script itself
crashes due to some error, your'e stuck with the backlight on. If the
script is killed, you're stuck with the backlight on.

Now, this goes for the app as well. But I edit my scripts and sometimes
make a mistake. I don't edit binaries.

Helge Hafting

_______________________________________________
Shr-devel mailing list
[hidden email]
http://lists.projects.openmoko.org/mailman/listinfo/shr-devel

[Tom-6]

Helge,
No, that's what you got wrong! As I said, the framework is supposed to auto free the resource just for cases like these.

Bill,
You may have witnessed a bug, and therefore should report, though the framework's specs clearly state that the resource is automatically released when the client leaves the bus (exactly for cases like I told helge about)
specs: http://git.freesmartphone.org/?p=specs.git;a=blob_plain;f=html/org.freesmartphone.Usage.html;hb=HEAD#ReleaseResource

It's quite informing, you should read more about it. Furthermore, you can use some of the functions discussed there to verify that I am in fact correct.

Good day.

On Tue, Apr 14, 2009 at 2:55 PM, Helge Hafting <[hidden email]> wrote:

William Kenworthy wrote:

On Tue, 2009-04-14 at 13:02 +0300, Tom wrote:

There are a couple of major advantages in using this app over a
script, the first:
with this app it'll work, with a script with mdbus calls it won't. ;]

mdbus calls work fine, though admittedly slowly - not sure what you
mean?

When the app that requests the resource closes, the framework
automatically releases it, so when you call mdbus request, the
resource is requested, though then mdbus exists and the resource is
freed, with this app it shouldn't happen (not sure how it wrote it,
though that's why an app is needed in the first place, just a simple
dbus call and a system() call.

This is an advantage to the script! - you make a call to request the
resource, and a second call to release it - its under your control when
you do it.

Assuming that the script works flawlessly. If the script itself
crashes due to some error, your'e stuck with the backlight on. If the script is killed, you're stuck with the backlight on.

Now, this goes for the app as well. But I edit my scripts and sometimes make a mistake. I don't edit binaries.

Helge Hafting

_______________________________________________
Shr-devel mailing list
[hidden email]
http://lists.projects.openmoko.org/mailman/listinfo/shr-devel

[Nicola Mfb]

2009/4/14 Tom <[hidden email]>:
> Thanks a lot, I'm glad someone finally did it!
> A few suggestions:
> I think adding a special flag for every common resource is a good idea, i.e:
> 'fsoraw --cpu --display APP' or even 'fsoraw -c -d APP' for quick cli usage.
> is more elegant in my opinion, don't you agree?

Hi Tom,
I'll add "long options" soon, but I prefer to have the -r
"resource1,resource2,..." or --resources "resource1,resource2,..."
approach instead of "--cpu --display", as the number of resources may
vary from device to device and time to time, so it's better to have
them not hard-coded.

> And I also think -f should be on by default, afterall it'll be used "behind
> the scenes" and normal users would want the app to run even if not possible
> to ask for the cpu... just my opinion though.

I just followed suggestion at
http://trac.freesmartphone.org/ticket/393 , but we may change the mean
of "-f" from "force" to "fail if some resources is unavailable" :)

Regards

      Nicola

_______________________________________________
Shr-devel mailing list
[hidden email]
http://lists.projects.openmoko.org/mailman/listinfo/shr-devel

[William Kenworthy]

On Tue, 2009-04-14 at 15:21 +0300, Tom wrote:

> Helge,
> No, that's what you got wrong! As I said, the framework is supposed to
> auto free the resource just for cases like these.
>
> Bill,
> You may have witnessed a bug, and therefore should report, though the
> framework's specs clearly state that the resource is automatically
> released when the client leaves the bus (exactly for cases like I told
> helge about)
> specs:
> http://git.freesmartphone.org/?p=specs.git;a=blob_plain;f=html/org.freesmartphone.Usage.html;hb=HEAD#ReleaseResource
>

Its not a bug as mdbus is not a client.  The application is a client,
mdbus is a tool to analyse and manipulate the various methods.  Using it
like this in scripts is probably not its intended function, but it
works.

BillK

* I had a look at the mdbus code - few comments and little information
as to what its supposed to do.


_______________________________________________
Shr-devel mailing list
[hidden email]
http://lists.projects.openmoko.org/mailman/listinfo/shr-devel

[Nicola Mfb]

2009/4/14 William Kenworthy <[hidden email]>:
> I think you misunderstand how mdus works - because it certainly doesnt
> work like that in practise!  i.e, when you request cpu the FR doesnt
> suspend, when you request display the display stays on.  When you
> release the resources by a further mdbus calls, it goes back to the
> prior settings.  i.e., you request a resource, its not relesed when
> mdbus exits.
>
> BillK

I guess you are speaking of two different things, I call
freesmartphone dbus api, not ophonekitd.

Regards

    Nicola

_______________________________________________
Shr-devel mailing list
[hidden email]
http://lists.projects.openmoko.org/mailman/listinfo/shr-devel

[Nicola Mfb]

2009/4/14 Tom <[hidden email]>:
[...]
> needed in the first place, just a simple dbus call and a system() call.

It spawn a child process with a fork and exec the application, so no
shell overhead (system calls /bin/sh -c), it's very fast.

> Second of all, mdbus takes a couple of seconds to start, so 2 consequtive
> call to mdbus make apps terribly slow to launch, this app shouldn't have any
> impact.

Yes, and in the case you are wrapping a python application with that
script you load the the intepreter three times before seeing anything,
as saied it's slow.

The last, it log errors to syslog to help debugging if something goes wrong.

regards

    Nicola

_______________________________________________
Shr-devel mailing list
[hidden email]
http://lists.projects.openmoko.org/mailman/listinfo/shr-devel

[Nicola Mfb]

2009/4/14 Helge Hafting <[hidden email]>:
[...]
> Assuming that the script works flawlessly. If the script itself
> crashes due to some error, your'e stuck with the backlight on. If the
> script is killed, you're stuck with the backlight on.
>
> Now, this goes for the app as well. But I edit my scripts and sometimes
> make a mistake. I don't edit binaries.

If fsoraw crashes, fso will monitor dbus disconnection, and will
release the resource automagically.

Regards

      Nicola

_______________________________________________
Shr-devel mailing list
[hidden email]
http://lists.projects.openmoko.org/mailman/listinfo/shr-devel

[Sebastian Spaeth]

William Kenworthy wrote:
> Ive sent it the list a couple of times in the past - its actually not

> mdbus -s org.shr.ophonekitd.Usage /org/shr/ophonekitd/Usage
> org.shr.ophonekitd.Usage.RequestResource 'CPU'
> mdbus -s org.shr.ophonekitd.Usage /org/shr/ophonekitd/Usage
> org.shr.ophonekitd.Usage.RequestResource 'Display'
>
> /usr/bin/tangogps
>
> mdbus -s org.shr.ophonekitd.Usage /org/shr/ophonekitd/Usage
> org.shr.ophonekitd.Usage.ReleaseResource 'CPU'
> mdbus -s org.shr.ophonekitd.Usage /org/shr/ophonekitd/Usage
> org.shr.ophonekitd.Usage.ReleaseResource 'Display'

But there is no way this would work. A resource is released as soon as
the dbus connection ends, which in the case of mdbus is... immediately.

That's a a wrapper binary is convenient, there is no way to achieve that
with mdbus calls beyond setting the resource policy (which has no
reference counting)

spaetz

_______________________________________________
Shr-devel mailing list
[hidden email]
http://lists.projects.openmoko.org/mailman/listinfo/shr-devel

[Sebastian Spaeth]

Sebastian Spaeth wrote:

>> mdbus -s org.shr.ophonekitd.Usage /org/shr/ophonekitd/Usage
>> org.shr.ophonekitd.Usage.ReleaseResource 'CPU'
>> mdbus -s org.shr.ophonekitd.Usage /org/shr/ophonekitd/Usage
>> org.shr.ophonekitd.Usage.ReleaseResource 'Display'
>
> But there is no way this would work. A resource is released as soon as
> the dbus connection ends, which in the case of mdbus is... immediately.

I am sorry, I got it wrong again, if you are requesting
org.shr.ophonekitd.Usage.RequestResource 'CPU'

from ophonekitd rather than raw FSO it will survive the mdbus call.
Sorry my bad.

Still, mdbus is the slowest option you can possibly use. Look into
dbus-send which is installed by default. It is much quicker to send off
a dbus command.

spaetz

_______________________________________________
Shr-devel mailing list
[hidden email]
http://lists.projects.openmoko.org/mailman/listinfo/shr-devel

[Nicola Mfb]

2009/4/15 Sebastian Spaeth <[hidden email]>:
> Sebastian Spaeth wrote:
>
> I am sorry, I got it wrong again, if you are requesting
> org.shr.ophonekitd.Usage.RequestResource 'CPU'
>
> from ophonekitd rather than raw FSO it will survive the mdbus call.
> Sorry my bad.

My personal humble opinion:

*) general applications should talk to FSO, not SHR specific dus api,
as they may run on different distros
*) the RequestResource api adds a double layer, I do not understand
the reason for that, please show me!
*) if ophonekitd crashes all resources are released
*) if the above script with mdbus calls crashes before releasing the
resource, this will be allocated for ever.
*) the same if an applications crashes or forgots to release resources.

The last two are importants as unpredictible crashes/human developing
error are commons, my personal experience :)

And finally the client vanish approach in the dbus world is a
standard, for example if you have a bluez agent and it crahes,
bluetoothd deregister it automagically.

Regards

      Nicola

_______________________________________________
Shr-devel mailing list
[hidden email]
http://lists.projects.openmoko.org/mailman/listinfo/shr-devel

[Tom-6]

Exactly what I think. I too don't understand the reason for the "double layering".
And all of the points stated are absolutely correct and critical.

On Wed, Apr 15, 2009 at 1:31 PM, Nicola Mfb <[hidden email]> wrote:

2009/4/15 Sebastian Spaeth <[hidden email]>:

> Sebastian Spaeth wrote:
>
> I am sorry, I got it wrong again, if you are requesting
> org.shr.ophonekitd.Usage.RequestResource 'CPU'
>
> from ophonekitd rather than raw FSO it will survive the mdbus call.
> Sorry my bad.

My personal humble opinion:

*) general applications should talk to FSO, not SHR specific dus api,
as they may run on different distros
*) the RequestResource api adds a double layer, I do not understand
the reason for that, please show me!
*) if ophonekitd crashes all resources are released
*) if the above script with mdbus calls crashes before releasing the
resource, this will be allocated for ever.
*) the same if an applications crashes or forgots to release resources.

The last two are importants as unpredictible crashes/human developing
error are commons, my personal experience :)

And finally the client vanish approach in the dbus world is a
standard, for example if you have a bluez agent and it crahes,
bluetoothd deregister it automagically.

Regards

     Nicola

_______________________________________________
Shr-devel mailing list
[hidden email]
http://lists.projects.openmoko.org/mailman/listinfo/shr-devel

_______________________________________________
Shr-devel mailing list
[hidden email]
http://lists.projects.openmoko.org/mailman/listinfo/shr-devel