[Kde-pim] scriptable resource

[Volker Krause]

On Wednesday 18 June 2008 21:23:32 Kevin Krammer wrote:
> On Wednesday 18 June 2008, Volker Krause wrote:
> > On Monday 16 June 2008 12:08:33 Kevin Krammer wrote:
> > > On Sunday 15 June 2008, Igor Trindade Oliveira wrote:
> > > > Hi Akonadi developers,
> > > >
> > > > I am sending this email to ask how you imagine that if you are
> > > > programming a scriptable resource(using kross) it look likes? for
> > > > example:
> > >
> > > Just to add a bit of context:
> > >
> > > One of our ideas regarding the Akonadi test framework is to have a
> > > resource which exposes some functionality through the Kross bridge to
> > > script languages.
> > >
> > > This is not, at least not at this point, intended to be a generic
> > > Akonadi "binding", the exposed functionality should be geared towards
> > > driving test scenarios e.g. simulating most common resource behavior to
> > > test a client or simulating most common client operations to test
> > > another resource.
> >
> > I'm still a bit confused about the term "scriptable resource". It
> > suggests that you would want to implement a resource in a scripting
> > language instead of testing a resource using a test script. Maybe that's
> > actually what would want to do but my impression was that your SoC
> > project was rather the latter ;-)
>
> Your interpretation of scriptable resource is basically correct, however it
> is just an option to perform testing task during the test run.
>
> There is a test executor or runner, which controls stages like setting
> environment variables, lauchning processes, terminating processes, etc.
>
> The scriptable resource idea is an option to have an active participant of
> the test setup. It doesn't necessarily have to be a resource, any kind of
> client would do, but since testing will always need some resource, I
> thought using the same thing would allow a very reduced setup.
>
> > For testing clients any resource that implements all operations and can
> > provide dummy data is fine (there is even a dedicated testing resource
> > called "Knut" in svn), I don't see the need for scripting here.
>
> Right, Igor should definitely have a look at the Knut resource.
> The scripting part is useful when you want to do timed operations, e.g.
> simulate a resource that got a backend notification, or react on operations
> from the test subject, e.g. assiging a remote identifier to an item created
> by the test subject.
>
> When running as a client to test a resource, it might be nice to react on
> things like the test subject's state, e.g. waiting until it has completed
> synchronize()
>
> In the latter scenario one could just use a script and let it execute
> commands by calling a commandline client, which remains as an option if
> preferred by the developer.

Right, there are indeed valid scenarios where one would want to customize the 
resource behaviour. Manipulating the actual data is another one I guess.

> > However, testing a resource needs quite some customization since most
> > resources have different capabilities, provide resource-specific
> > attributes, provide additional operations, etc.. So, that's where
> > scripting makes a lot of sense IMHO, but not for a resource since testing
> > a resource from another resource is probably not a good idea.
>
> In this case it would just act as a client or "normal" agent.
> Does this approach violate any assumptions in API or server?

Resources are managed by akonadi_control, starting them manually is not 
guaranteed to work. Starting resources as "normal" clients might work, 
however resources will automatically register with their corresponding 
service names on D-Bus. Not sure if this causes problems, might work if you 
use an resource type name and identifier that's not used by Akonadi.

It might be better to separate that, the scripting API should be the same in 
both cases anyway. Maybe adding scripting hooks to the Knut resource to react 
to data changes or sync requests would be an alternative.

> > > So the question is how would you expect to be able to write such
> > > scenarios (pseudo code style), e.g. which objects do you need, which
> > > operations on each object is necessary, etc.
> >
> > One thing I would expect the testing framework to do is to deal with the
> > async operations for me. Writing fully async code is necessary for
> > clients, but quite cumbersome and for testing we don't really need that.
> > See my reply to the "akonadi testing framework" thread for the operations
> > needed for testing resources.
>
> I am not 100% sure I get what you mean. If you meant that the test needs to
> be able to wait for and detect when an operation has finished, then this is
> why I think it is a good idea to have a permanently connected test
> participant, getting notifications, etc.

What I meant is that I don't want to write a result slot for every operation I 
do ;-) API-wise this could be: Item::List items = fetchItems( parentCol ); 
instead of the usual job stuff.

> > Another thing that might be useful for testing but is rarely needed in
> > normal clients is a easy way to convert between remote and local ids.
> > Since resources work mostly on remote ids you likely need to deal with
> > them as well during testing.
>
> Right, good point.

regards
Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20080619/d2c3f9db/attachment.sig>
-------------- next part --------------
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/