[ghns] DXS implementation point of view

[::... 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(

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.

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.

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

Simplicity is very major things too. Its if we make it to complicated or
too big - nobody goes to use it.
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.

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.

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)

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.

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)


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

-- 
Kulyk Nazar