David, I'd be happy to be your mentor on this -- I'm excited to get this functionality in Inkscape proper. I think that developing it in a sandbox was good for the senior project, but to be truly useful for most people, it needs to be in the Inkscape codebase.
On Sat, 2005-06-25 at 17:29 -0500, David Yip wrote:
On Saturday 25 June 2005 04:55 pm, you wrote:
One of the issues that I saw in the previous inkboard development, that I would love to see you address is that the work was pretty 'disconnected' from the rest of the Inkscape team. The discussion was done external to the normal Inkscape channels, and the code was hosted out of a separate CVS. Of course, this was due to the necessity of the way their project was structured, so this was completely understandable. However, it's meant that the inkboard capabilities aren't available in Inkscape itself; the code is external from the inkscape codebase, and the Inkscape team lacks understanding of the code.
No problem; I can do that.
Good, the only thing I'm worried about right now, is how much of this do we want to put in right now? In theory, we're stabilizing for a release, although it is going slowly (I've been working on distcheck all week :( This is more of a question for the list.
There's a lot of documentation on inkboard.sourceforge.net (thank goodness for Rose-Hulman senior project standards ;) ) that I think will clear up a lot of their code, and I've been looking over it on the past few days. Additionally, a big chunk of the code is in inkboard.cpp, which means that we don't have to do a lot of hunting around in the source tree. (Though breaking that file up would probably be a good idea.)
Yes, this was on purpose, the idea was to make the reintegration easy. I think the most difficult thing will be naming changes. The largest of which is the SPRepr -> Inkscaoe::XML::Node change. Unfortunately that change was made after the split.
Now, the main thrust of your proposed effort is geared around stabilizing the inkboard functionality and turning it into something ready for production. I can suggest a technique for achieving this.
Years ago I was developing an online game server with some other folks, but there were a number of stability issues, and we lacked a lot of rather simple features, and the more coding that went on, the more unstable the software seemed to get.
Finally, I decided to organize weekly meetings in the game server itself, according to the "eat your own cooking" philosophy.
Sounds good -- I think Inkboard, as it stands, is stable enough to support such demonstrations, and from what I've read of the Inkboard design documents, it does support multiple users. (I've admittedly never seen that demoed, though -- all Inkboard demos were carried out using two peers -- so I'm going to ask the Inkboard team if that really does work :) ) There's no explicit chat facility as far as I know, but other methods of communication should work fine. Also, since Inkboard is based on Jabber, it shouldn't be too hard to hack in a rudimentary chat facility -- but I'd rather not get ahead of myself just yet :)
Inkboard's original design had multiuser chat in, so the design should be flexible enough to handle it, but we just ran out of time. I know that some of the code is in there, but I asked them to go and document it rather than trying to tinker and make it work. Hopefully, it should be easy to complete (and I'd love it if you did that) -- but, I never verified how much documentation was put in.
Overall, cool, I'm excited that this project got chosen. Put together a schedule, and we can talk about it. I think, for me, the first priority would be integrating into the full codebase, and then getting the chatroom stuff working. Then, doing the sever registration stuff. I'm not sure how useful the server registration stuff is without being able to share the document with multiple people.
Glad to have you on the team David.
--Ted