[daisy] [GSoC] applying for the development of a .NET library for Daisy

[Marc Portier]

christophe blin wrote:
> I think that it is a matter of simplicity : WSDL is a lot heavier than
> REST with embedded XML to do request and to transform the response
> 
> For example, try to imagine the complexity of a publisher request if it
> was to be done via a function call.
> Also, you will have to deal with complex type (for example the Document
> type) and you do not have this problem with simple XML.
> 
> just my 2 cents.
> 
> chris
> 
> 


well, I think it's worth a lot more then that :-)
it is precisely the nature of the matter
(Ok, with the slight nuance: I think SOAP is a lot heavier, rather then
WSDL)

Having said that though I'ld like to reverse Cyrille's question here:

> Cyberchand a écrit :
>> Marc Portier a écrit :
>>> I think this proposal should take a change in strategy.
>>>
>>> To be more concrete I think the project should deliver one selected
>>> application of the suggested Daisy.NET usages (the word plugin, the
>>> asp.net or whatever custom client) describe what that will do, how it
>>> will work, and which parts of the Daisy API that will touch upon (thus
>>> what would be available in the resulting Daisy.NET lib)
>> Why do you think that the remote API cannot be simply written using a
>> WSDL format? May it be possible to imagine functions, running as
>> webservices, like GetDocumentVariant(id, branch, ...), or
>> MakeQuery("select ... from..."), etc ? I mean, when you developed the

Why do you think it is impossible to write a WSDL file that describes
our handcraft/design HTTP/XML API.
(rather then let it be generated to describe a new SOAP based API?)

That would result in THE SAME existing HTTP/XML API to be reused by
clients that get generated from that WSDL.

I really don't even know if it _can_ be done, but at least investigating
_that_ is what I was trying to propose...  you went directly over to
something completely different in stead...


Why do people think WSDL should be generated? WSDL is an interface
definition language (like IDL) it should come first, not generated
backwards from an existing implementation, just my 2c.

see also these articles from Johan Peeters:

http://webservices.xml.com/pub/a/ws/2003/05/27/wsdl.html
http://webservices.xml.com/pub/a/ws/2003/06/24/wsdl.html
http://webservices.xml.com/pub/a/ws/2003/08/05/wsdl.html

I know the dude, his mantra is 'write WSDL by hand'

>> actual HTTP/XML api, you may had that idea, but for what reasons did
>> you choose the actual implementation, instead of a webservices
>> oriented interface, which might be more convenient to use? (It is my
>> personal opinion though...)
>>

Well, with all respect, rather then a personal opinion, to me, it sounds
like a vague idea blown up by available tools and their commercial
vendors :-)


Well, I'm not in for a big SOAP versus ReST debate here, and frankly I'm
too much of a pragmatics guy to be interested in victory of either side,
I'm more interested in some smart mix of all knowledge comming from
either side. Sot when you read up on all that is said in that debate,
and you _do_ take a grassroots, handycraft and practical view of things
I think there is an easy case to be made on the elegance of the more
ReSTy approach we've taken.

>> However, as you seem very not convinced by the idea of writing a
>> second API (and it is understandable... moreover it is not actually
>> conceivable to change the entire api because of the lack of
>> retrocompatibility that would follow), I got back to a variant of my
>> first idea, and I changed (once again...) my proposal ! I hope it will
>> be the good one :o)
>>

I'll check shortly,
In the mean time do check also the list on the recent 'modification of
attachments' question, there might be an entersting use case there in a
real handy application for (typically windows based) end users.

regards,
-marc=