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

[Marc Portier]

Cyberchand wrote:
> Hi,
> 
> thank you for all your remarks. I'm going to respond briefly to them
> here, and I'm working at the same time on an new version (which will be
> published tonight) of my proposal (at the right place now,
> http://cocoondev.org/daisyscratchpad/g5/394-cd.html).
> 
>> in general there seems to be some conditional wording in your proposal
>> that makes it a bit vague on what you're actually committing yourself to
>>
>> I understand of course this is just a first shot, and a more detailed
>> plan of attack will need to be built, but don't let some polite way of
>> wording make us think you don't have an opinion or clue :-)
> 
> All right, in fact the first version of my proposal had been written to
> raise some ideas about a .Net implementation of the Java API, and
> especially to raise feedbacks from the list. Now that I have some, it
> helps me a lot to do a more precise proposal ;)
> 

cool, I've seen it popup on the mentor section of the gsoc site

knowing you had some difficulty earlier I expect you'll find the time
shortly to complete your entry at

http://cocoondev.org/daisyscratchpad/g5/394-cd.html

(I edited the 'category' to let it show up under the google soc projects)


>> * how and when are you planning to learn DaisyCMS (have you discovered
>> the +300 page manual yet? how much of it is read and known? where do you
>> (think you will) need help to understand? how to organize that? have you
>> built from source/installed and tested the current Daisy?)
> 
> I have already read a large part of the documentation available on the
> Daisy website (especially the pages in the "Repository server" category
> : the basics about documents, ACL, query language, and the Java and HTTP
> programming interfaces). I also spent some time on the javadoc.
> I already downloaded the source code thanks to svn, but I didn't try to
> compile it yet nor to do some tests with the API. It would be the first
> part of my job actually :) (and it won't take more than two days).
> So, I have a good idea of how Daisy is working, and I do not need more
> to begin the work. My knowledge of the actual Daisy implementation will
> increase while I will be working on it. It's the way I work. :o)
> 
>> * how much time do you think you need to really just do the groundwork
>> of making the remote API implementation available in C# (do you really
>> think there is going to be time any/all of the suggested clients?)
> 
> I should have precised this in my "first shot" : the different ideas I
> gave (Windows GUI, ASP.NET implementation) were nothing more than
> "possible ideas", and I actually didn't plan to really work on them. It
> was just there to give some concrete applications of what my work would
> be used for on the future. The primary goal of my work would be to
> provide a .NET library (basically, DLL files) which would provide
> different .NET classes designed to manipulate a Daisy repository without
> pain. Thanks to these DLL, the development of a project like an ASP.NET
> wiki, a MS Office plugin, or whatever, will be much more easier than
> with manipulating complex HTTP/XML requests and responses.
> [i have used the conditionnal here because my plan changed a bit after
> certain of your remarks below - you will see what I mean at the end of
> the mail :o) ]
> 
>> * I didn't know about the Language Conversion tool (is it free/open?)
>> and it looks like a viable and direct way towards solving the issue.
>> However my personal idea would have been to rather provide some wsdl
>> like description for our rest based API and let the standard wsdl
>> interpretation and code generatrion stuff take it from there. (I admit I
>> haven't thought this through, I'm sharing my naive thoughts, your
>> comments and insight is appreciated)
> 
> I think it is indeed a good idea to provide a web services oriented
> interface. It may be easier to use for a client. For now, a non-Java
> user must write the HTTP request to retrieve a document/make a
> search/whatever with a syntax defined by Daisy, while a Java-user has
> access to a Java-API whose job is to basically convert Java-code into
> the right HTTP request (or am I wrong?). If we could provide web
> services, a client could use the language of his choice to communicate
> very easily with the Daisy repository server.
> So I think that idea is better than converting all the java code into
> C#, because in the latter case, we would have to maintain the C# code
> updated in real time, which would take a lot of time.
> 
> In brief, here is a new strategy which may be more efficient (as usual,
> I will accept feedback with pleasure :o) :

well, still the same vagueness remark exists, I was just suggesting the
webservices idea and it turns out to be changing your proposal
completely (I like having that kind of impact of course :-))

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)

As confusing as things might sound: but your proposal would benefit from
- either abandoning the webservices idea because you have no
clue/time/interest
- either showing you do have a clue and listing the possible issues you
foresee and want to investigate into during the start of the project

(excuse my blutness)

that and a more detailed planning of your planned activities...

> - make the precise list of the functions that will be published in web
> services, and which will be usable by clients almost as easily as usual
> functions,
> - use a java library to effectivly publish the web services (Axis for
> example),

I assume here you hope some axis tools would generate the wsdl file?

> - then, write a .NET library that will encapsulate the dialog with the
> web services. That step is not absolutly necessary, but it may be useful
> to users who do not want to know how to use web services.
> 
> For the first step, I will need to do it with the help of the Daisy
> community. It is the Daisy users who, after all, can tell which
> functions may be the more practical to use.
> 

naieve first starting point should be
http://cocoondev.org/javadoc/daisy/2.0/index.html

and then
1/ delete what is not useful (menaing you shouldn't do more I guess then
what is published in that API)
2/ prioritise: in my mind content authoring support should be first,
directly followed by publishing, but other opinions could be there

> I am going to precise that in the second version of my proposal.
> 

looking forward,
-marc=