[ghns] DXS implementation point of view

[::... SchAmane ...::]

У Ндл, 2005-07-03 у 19:25 +0200, Josef Spillner пише:

> In July I also have a couple of exams. Yet I'll try to find enough time.

Same here, than i am on vacation, away from PC ;o)


> > First of all i am not good in English
> No problem at all.
> Most of us here don't speak English as a mother tongue I suppose ;)

Ok ;)

> Usually if the web server supports mod_gzip or anything like that, the size 
> should shrink automatically.

I see, but it should be supported first on client side...

> Limiting the number of items per response will help also, and this is what the 
> webservice methods will be for.

Yes, this is normaly good way not to ask about whole list of items. But
i am still not sure about usability of XML in our case. I and Michael
are same mind about this. We dont need xml in any case. We prefer to
work with Objects throw SOAP. Just stransfer Objects(Classes or
Instances) with method calls.


> I agree that a WSDL is site/host specific. The essence of it for us are the 
> message descriptions (or API as you said).

First we need to document( visualize) with UML, or Use Cases some
processes which would be found between client and server. Than we can
start to define some API witch build up this processes.

> So we should probably only standardise the messages, but still provide a 
> standard WSDL file as a non-normative addition, just like we do with the 
> providers.xml file right now (which has entries such as 
> "http://some.server.tld").

We have first try with PHP DXS on our side. If there is some interests i
can show it. Provide sources or explain how we think it will work.
Do you people have contact with KDE-Look developers ? Is somebody hear ?
Is KDE-Look interested in this projekt ?

> > What we should define if we will arrive Flexibility. We can define
> > namespaces, or names of methods, or even way how client should ask
> > something he will from server. But we dont should define what is
> > provided on server or client side.
> 
> OK, point taken. This will be of importance once the standard is to be 
> written.

I think we need to specify what methods on server side do what for SOAP.
Second problem is with ComplexTypes. It should be transparent for client
for every service. So result given from AGO service provider returns
Item and KDE-Look service provider Item is same think for client. But as
i know AGO saves different attributes for Theme items than KDE-Look. I
dont know how big it is problem for client side.

> > Simplicity is very major things too. Its if we make it to complicated or
> > too big - nobody goes to use it.
> Exactly!

That is why i think we need only few major methods to define. Rest
should be done with "patterns" or "Categories".
Problem would be only with result. Result can be an Icon, or Wallpapper,
or GameItem. In this case we need generalize it, or find another way.

> I recently had a look at the eBay API.

Yes, whole stuff should be good documented and be very simple. Some
basic code examples with different languages(perl,ruby,mono,php) would
be welcome to.
I think it would be good to have wiki system for this.


> > How to push methods count down? Easy. We put two methods : getWallpapper
> > and getIcon together: getTheme(Category,id,user); Where Category can be
> > XPATH like string as example:
> > "//wallpappers/wallpapper[category='nature']"
> > or:
> > "//icons/icon[recent=1]"
> > Any way it can be done in another way. And this is what we need to
> > define.
> This puts category and additional information ("recent") into one field. I 
> would keep them separate.

Why ? You give bouth of paramethers in same place, so there is way to
put it together on client side. You dont need to write it if you ask
only for icon list and you can put it if you expect to get only recent
items. You can even specify how many matches you will recive.
I think XPATH should be very easy to use, especialy if result you get
from DB is allready in XML form.

You can build very different querys with XPATH. Very easy or very
complicated.

/first/second
    Match any <second> elements that occur inside a <first> element that
is the root element of the document
 
//second
    Match all <second> elements irrespective of their place in the
document
 
//second[@hi]
    Match all <second> elements with a 'hi' attribute
 
//second[@hi="there"]
    Match all <second> elements with a 'hi' attribute that equals
"there"

//item[contains(item/author,'Winer') and
contains(item/author,'Pilgrim')]
... and so on


As supper feature we can use XQuerys, it makes all very flexible, but is
more complicated for client side than XPATH.
http://de.wikipedia.org/wiki/XPath
http://de.wikipedia.org/wiki/XQuery


Maybe somebody can provide us with better sugestions ?


> > I can explain our first need ( from A.G.O service provider view):
> > .Authentefication (can be done throw HTTP-AUTH in SOAP)

> The authentication is something I didn't yet look at, good point.

There are some difficultys. I would like to have shema like this:
1. user do auth
2. user can use authentificated service.

but SOAP is static. It means that after remote call is done, server
forget everything about user authentification. We can provide user with
some TEMPORALYID after authentefication, and save who this user realy is
in to the DB. So after next every remote call user should submit his
TEMPORALYID.
This is not so easy. We need provide basic security for this, maybe
check his IP or something more. Best - Authentification call should be
done throw SSL. And we need more DB for this. If server goes to be very
popular we need big DB. And major problem - on deploy our peace of code
(let say it would be php code) we need configure DB too. If we dont use
DB - you can just put PHP code to download somewhere, show user how to
configure this PHP code to work with his DB resources and thats all.
Another, simplier way would be just submit "username" and "password"
throw URL (HTTP-AUTH):
http://user:password@server.org/webservice/service
for every webservice call.
On server if user call to some funktion what need user-auth, like
posting comments - you get server variables and do match username and
password with your DB. If you dont need it, you can just ignore this. If
client dont have useraccount at this time, he dont submit it and get an
error on calling specific methods.

> The GetListOfItems I have now already implemented in the perl module.

How you do this ? Do you give server side know how many items you will
ask?

> > There should be an easy way to habe UniqueID for every Item. Thats where
> > we dont have solution on this time. A would be happy about any
> > sugestion.
> Maybe one could use the internal database OID, or an MD5 checksum.

Thats problem. On AGO as i know is no UID on database for theme items.
this means, icon item and wallpapper item can have same ID.
MD5 can be solution, but there are coalisions.
Second problem. Maybe we will submit to server from client what Desktop
Theme he use. But this theme has more then one version. Maybe user use
old one. So how to calculate MD5 ? Should it be different for defferent
versions? This are problems we dont have at this time, bacause we will
start with major functions first, but maybe same days =) "wir sind so
weit" ;o) ?

> Also:
> setRating

Yes, this is what we strongly need too.

> setSubscription -> sort of "bookmark" to find out about updates of your 
> favourites

Nice idea. But i dont get what you will recive as result?

> This already works for many games.

We dont include games and other stuff to our work. We will implement
only interaction of desktop with web page(AGO) but i would be happy if
this would be extendable for all other needs from basic design.

> > Maybe somebody can join me on IRC to take a little explanation
> > conversation about what allready is done, and what you exactly expect as
> > result of this work.
> Which network, which channel, which nickname? :-)

I and Michael are allways to find on server: irc.gimpnet 
channel: #gnome-art

my nickname is "tirpse". There is also "thos" - main AGO developer and
"miketech" - Michael.

-- 
Kulyk Nazar