[Kde-pim] scriptable resource

[Kevin Krammer]

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.

> 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? 

> > 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.

> 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.

Cheers,
Kevin

-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20080618/139de738/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/