[ghns] DXS implementation point of view

[Josef Spillner]

Hello,

Am Sonntag, 3. Juli 2005 16:25 schrieb <::... SchAmane ...::>:
> Hi all,
>
> i was starting to do some work with Michael Gebhart for art.gnome.org to
> provide basic interaction between desktop and services provided by web
> site. Now its stoped, because we dont have time for this. :o(

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

> First of all i am not good in Englisch, i never learned it in the scool
> or uni and its my very second language, so sorry if something is
> misspelled or not understandble. I am allways happy to give you more
> explanaition about what i mean, if you ask me for this.

No problem at all.
Most of us here don't speak English as a mother tongue I suppose ;)

> Ohnestly, i dont haved time to overview all things you writen on ghns
> web page. There is a lot stuff what i dont undertand and more stuff i
> even will not  understand because i dont need it.
> I read you maillist, and i see little problem here in design of our
> work.
>
> There are major point i dont get:
> 1. What for is XML here ?
> 2. Why define WSDL ?
>
> Ok, now more about this points.
> 1. XML is nice cool stuff, but generaly bad in using with problemms and
> needs wee have. Let see. If somebody ask A.G.O( art.gnome.org) for list
> of themes, in worscase be became XML in size of 1Mb. If application will
> use this XML, user must wait until application get whole XML and than to
> parse it and get 10 items from there. Its very unusable.

Usually if the web server supports mod_gzip or anything like that, the size 
should shrink automatically.
Limiting the number of items per response will help also, and this is what the 
webservice methods will be for.

> 2. We shouldnt define WSDL. Point. Thats completely bad way. What we
> should than ? We need define some API. WSDL is only transport way to
> provide remonte calls on server from application. So this is bad way in
> design to define WSDL. WSDL should be automaticaly generated on every
> service provider from his API. More - on different services there should
> be different WSDL.

I agree that a WSDL is site/host specific. The essence of it for us are the 
message descriptions (or API as you said).
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").

> Let explain. We habe two providers. First - A.G.O, second - KDE-Look.org
> Let say. A.G.O will provide to user all information about stored
> Wallpappers. And KDE-Look.org will only give information about recent
> Themes(not only wallpappers). So in your case( if WSDL is genraly
> defined and is exactly same for all serivce providers) KDE-Look.org
> should implement functions to show all Wallpappers, and in the same way
> A.G.O should implement methods to show recent Themes.
> This is not good in many cases. If wee will that somebody use our
> standarts we need two things:
>
> 1. _ SIMPLICITY _
> 2. _ FLEXIBILIY _
>
> 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.

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

Exactly!
I recently had a look at the eBay API.
Never used eBay (and will never use it), and it was such a huge unstructured 
list that also made me decide to never use their webservice.
So in addition to the API, we should definitely also have some kind of "first 
steps" tutorial, so people can learn step by step which API methods are the 
most important ones for them.

> It means, we need as small methods count as we can get, as basic as we
> can make it. And every process should be mirrored in new another method.
> Witch means - if we have getWallpapper(id,user); method than new method
> called getIcon() should have same paramethers count, same result way and
> so on. This is what we should work for and what we should define. Not
> the WSDL file.

OK.

> 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. getTheme(Category,id,user,pattern,mode) maybe.
Where pattern could be something like "*theme*" and mode something like 
"recent" or "mostpopular".

> I can explain our first need ( from A.G.O service provider view):
> .Authentefication (can be done throw HTTP-AUTH in SOAP)
> .Get One item( Wallpapper,icon,gtk-theme with his attributes)
> .Get List of items ( recent entryes, first 10 items alphabeticaly
> ordered, etc.)
> .Search item (if you only know "like" name)

The authentication is something I didn't yet look at, good point.
The GetListOfItems I have now already implemented in the perl module. It 
queries the database in the backend and then returns the list of a certain 
category. It does not yet support mode, search patterns and the like.

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

> In second needs(we dont do implement this in first release):
> .give provider information about Themes used on client side
> .get comments for Theme Item
> .send comments
> . etc. ;o)

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

> As i understand you all will do more extendible platform, to provide not
> only Desktop Themes, but Game items and so on. How can this be done? Any
> sugestion allready there?

This already works for many games. But we don't have a stable server setup 
yet. Each application simply downloads a file (or archive), and then calls an 
application-specific uncompression/installation/post-installation code on it.

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

Which network, which channel, which nickname? :-)

Josef