Hello all,
First, I apologize if this message is misdirected. I've seen Summer of Code-related topics in this list before; however, I also know that John Cliff is the point of contact for SoC proposal discussion, but I'm not sure if he is also involved in mentor assignment.
With that said, I'm interested in how mentor assignment will occur -- will there be a separate list, one-to-one correspondence, or some other method? My project proposal involved the integration of Inkboard's code with Inkscape's main trunk, along with a few extensions to the idea. I would like to clarify required and optional deliverables and agree upon scheduling, etc.
Thank you,
David Yip
On Sat, Jun 25, 2005 at 11:56:05AM -0500, David Yip wrote:
Hello all,
First, I apologize if this message is misdirected. I've seen Summer of Code-related topics in this list before; however, I also know that John Cliff is the point of contact for SoC proposal discussion, but I'm not sure if he is also involved in mentor assignment.
Yup, this is the right place to ask! :-)
With that said, I'm interested in how mentor assignment will occur -- will there be a separate list, one-to-one correspondence, or some other method?
Ted had been the mentor for inkboard previously; he's been pretty busy lately (moving, etc.) but he would be the logical person to mentor your project if he's available. If not, he'd still be an excellent resource regardless. Simarilius and I will work out who will be your mentor, but please get in touch with Ted to get the low-down on how things stand currently.
Regarding how to do the discussion, I have an idea... read on. ;-)
My project proposal involved the integration of Inkboard's code with Inkscape's main trunk, along with a few extensions to the idea. I would like to clarify required and optional deliverables and agree upon scheduling, etc.
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.
Thus, a key issue for you to help us solve is to remove this disconnect. I think the best tactic for achieving this is to start integrating the inkboard code into the inkscape codebase proper, and to spark discussions with other developers as you go. Hopefully, this will stimulate other developers to review the code and help you in stabilizing it and merging it with Inkscape proper.
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.
The first meeting was a disaster. Lots of people had trouble getting the client working, the server crashed within minutes, and we wasted the entire hour just trying to sort out what was wrong.
By the next meeting, though, people had sorted out a lot of the issues. The server spent more time down than up, and some people couldn't connect at all, but we were able to do much of our meeting in the server.
By the third meeting, the server software had mostly stabilized. By the fourth it was robust, and developers had started adding a lot of convenience functions into the client.
Given your system administration and networking background, I think you would be very effective at using this same tactic for inkboard. Set up and administer a copy of inkboard. Arrange a weekly 1-hour get-together on Inkboard and invite your mentor and any interested users and developers to attend. Use it as an opportunity to teach others how to install and use inkboard, and as a way to solicit ideas, bug reports, and feedback on getting the code integrated. Keep an eye out for bugs or misbehaviors and record all that you can find, and strive to eliminate them by the following meeting.
Bryce
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.
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.)
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 :)
David
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
On Sunday 26 June 2005 02:16 am, Ted Gould wrote:
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.
Hello Ted,
Sure thing -- it'll be great working with you!
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.
Right now, I feel that "none" may be the best course of action. For a while, I've been working with the latest version of Inkboard available off of inkboard.sourceforge.net, and, while I've had success in setting up two-person, one-way whiteboards, I've managed to crash Inkboard every time while attempting two-way communication -- gdb's backtrace reports some rather nasty stack corruption, so pinpointing where things are going wrong is a somewhat slow process. (I'll attach backtraces, debug output, and other such material in a few hours, if requested -- I'm dozing off even as I type this :) )
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.
I've not yet tried it out with Jabber chatrooms, but a look over the code seems to say that a lot of it is already flexible enough to handle the chatroom case. I'll give it a try in a few hours.
Overall, cool, I'm excited that this project got chosen. Put together a schedule, and we can talk about it.
No problem. I'll have that for you soon.
I think, for me, the first priority would be integrating into the full codebase, and then getting the chatroom stuff working.
I agree here, though I think there may be a good amount of work to be done re: improving performance and robustness. I'm running a Jabber server (jabberd 1.4.3) on my LAN, and performance seems to be extremely low; handshaking with a nearly blank document (just a yellow square near the center) takes minutes. However, I'm not sure if this is a issue with the code or my development environment, as I don't recall similar performance problems in the Inkboard project team's demos.
Glad to have you on the team David.
--Ted
Glad to be working with you!
-- David
participants (3)
-
Bryce Harrington -
David Yip -
Ted Gould