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

[Marc Portier]

Cyberchand wrote:
> Marc Portier a écrit :
>> seriously: I'ld prefer your plan to 'consider' this idea, and thus plan
>> time for evaluating it... for one I'm not sure that our REST based
>> interface is directly writable as clear and useful WSDL, so I'm not
>> convinced that axis will automatically will turn it into what we want
>> (for one I'm not fond of the idea of having axis generate client or
>> server java to wrap around the already working http-xml remoting
>> solution)
> 
> The code of the webservices won't rely on the already working http-xml
> remoting solution, but directly on the server api, written in Java. They
> will be actually running on the server.

yeah, but they will thus produce effectively a second, separate http/xml
API, right?


I've deliberately let this wait some time to think it over... however
I'm still far from convinced.


> Moreover, I do not plan to implement all the features that already exist
> for now with the http remote api. The idea is to propose a few functions
> available as webservices to help the occasional Daisy users (especially
> in non java environments) publishing and searching the repository server
> without pain. Instead of making some http requests with different
> parameters, they will be able to display with a single and simple
> command a specific document, or to display a list of documents
> responding to some search request.
> Again, the goal of this proposal is not to implement new incredible
> features, but simply to propose a very simple way to do the most basic
> tasks with Daisy.

probably, this boils down to the essential struggle this (and the
python) proposal is causing in my mind


Where is the added value?


* I see mostly in the "other language bindings", that after the effort
is completed an issue has emerged: how to keep them in sync both with
new Daisy releases and reported specific bugs or enhancement request
(only relevant to the typical development in that other language)
-- more trouble then added value?


* I see (in the case of the suggested webservices approach) a new
(auto-generated) http-xml based API. Which is thus a different
alternative to what we actually already have and currently promote as
the language neutral way to talk to the repo). Going through with this
in the suggested way is IMHO very likely going to confuse people since
there will be 2 XML/HTTP API variants...
-- added confusion, no (or little) added value


* I see no new things people will be drawn to. No stuff that will
effectively be used and help grow the group of users
-- no added value, only some "just because we can"


In other words:

We've suggested ourselves these topics around "other language
bindings"... but the more I think about it the more I'm getting
convinced of the fact that they really don't make a dent unless they
effectively produce something that is not feasible today, as part of the
project, and not as an "exercise left to the reader".  So yeah there
should be new features!

I've been the one to suggest the webservices approach, but it was never
my intention to suggest an alternative http/xml api.  (Yeah, I'm still
asking if our http/xml api can be written in a direct to use WSDL format.)



Now regarding:
http://code.google.com/support/bin/answer.py?answer=60325&topic=10729

> Interim Period: Mentoring organizations review and rank student 
> proposals; where necessary, mentoring organizations may request further 
> proposal detail from the student applicant
> April 11: List of accepted student applications published on 
> code.google.com by 5:00 PM Pacific time (00:00 UTC April 12, 2007)


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)


Note, the above is my personal feeling, I am just 1 mentor.

> For example, we could imagine a content provider, which would consist of
> a Daisy repository server read-only accessible to some webmasters. Then,
> these webmasters (programming with ASP.NET for example) could
> dynamically show an article, or a list of articles in relation to some
> keyword. It is very easy to do that using the webservices (in .NET at
> least), at the condition that these webservices have been well done.
> 
> Regards
> 

kind regards,
HTH,
-marc=