Hi Stephen, I sympathize completely with the issue of keeping documentation up to date. I hope that as "consumers" of the current documentation and the SDS services, Cynick, Hiroki and I can help to drive the documentation process in some way. I am certainly noticing that our "back and forth" discussions when we have a problem, as well as the problems we are creating for you seem to be driving SDS development to some degree. Portal development is helping to identify problems when they occur in the SDS. Hopefully the same thing will happen with the documentation.
I will speak to Cynick about creating our own SDS locally. Laurel On May 1, 10:13 am, Stephen Bannasch <[EMAIL PROTECTED]> wrote: > >Hi Stephen, > > >A page describing changes would be great, but I think newcomers would > >benefit from a single reference page which reflects the "current > >status" rather than having an older page and then a update page to > >refer to.... > > The documentation is hard to keep up to date. I'm looking for more systemic > solutions -- like adding functional and unit tests that not only test the app > but write what documentation about what they do. The development sds API is > not yet stable, people using the development SDS should expect to be part of > the development of that API. We need to do a better job communicating ... BUT > ... we have limited resources and there's a bunch of work to do ... so > sometimes the work is getting done without as much documentation as would be > good. > > Aaron's working on hacking in some more reporting features because TELS needs > that right away. These shouldn't be in the SDS but Aaron and I need to > restructure and update the code to move the whole SDS to rails 1.2.x to > better support deeper and much cleaner (an easier to maintain) REST access to > the SDS resource. After that is done writing an external researcher reports > app hat consumes data from the SDS will be MUCH easier. > > It is important to keep a set of documentation that refers to the running > production saildataservice separate -- so I'm going to fork the doc for the > new dev sds. > > The current documentation is checked into the source repository. I can > restructure the creation of the documentation so it is more like JavaDoc > (processed from comments in the source) and add to it the results of actual > testing (which can not only document the results but can also document the > specific way the test was performed). We can then also write a task which > takes all this work and automatically populates a tree of locked confluence > pages (changes should take place in the source) but on the pages additional > info could go as comments (which could be folded in to the documentation as > needed). > > You can also checkout the code itself to just read it to see what is > happening -- most of it is quite easy to read -- you can even make your own > local SDS using Aaron's instructions. > > The code is available to view on the web here: > > http://svn.rails.dev.concord.org/svn/sds/trunk/ > > >so I'm hoping you will just remove the older versions of > >the commands and replace them with the new versions. I'm noting that > >the "get" for the jnlp seems to return a significantly different > >response body now. Would appreciate that being updated too. > > In the meantime please post questions to the sail-dev list. > -- > - Stephen Bannasch > Concord Consortium,http://www.concord.org --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "SAIL-Dev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/SAIL-Dev?hl=en -~----------~----~----~----~------~----~------~--~---
