Pre-release Update
Sun, 17 Dec 2006 07:57:34 GMT
Firstly, I feel it is necessary to apologize for the long silence regarding the project. The team is very busy with school and other affairs and ultimately there is very little or no time left for slightly more awesome things. Fortunately, a large break is coming up, and at least I will be devoting almost all of my time to the new release. Here are some of the things I will be working on:
*UML diagrams of the entire 1.0 release. Everything with be fully documented and specifications will be so precise that if anybody wanted to write up an implementation for a class, the requirements would be very clear (much like the TopCoder contests). Also, I would like to see what we can do about a class status system much like the Mono Project, so it is easy to tell what needs to be contributed.
*Plugin Engine. We will also flesh out a nicer way of classifying plugins and what they do, with interfaces and everything. This will make more sense in the documentation and UML.
*Plugin repositories. Plugins should be obtainable and managed in the same way that Ubuntu manages packages with apt-get.
*Hopefully, and although this is not a priority, we will write all interface code in a language that can be interpreted by any user-interface package, for example XAML or XUL. This will allow for very easing porting / extensibility of UIs.
More details will be posted, and as always check the SVN repository for new code. I promise, the next commit will change the SVN repository to look like it should, with a trunk, branches, and tags.
Augie (0 comments)
*UML diagrams of the entire 1.0 release. Everything with be fully documented and specifications will be so precise that if anybody wanted to write up an implementation for a class, the requirements would be very clear (much like the TopCoder contests). Also, I would like to see what we can do about a class status system much like the Mono Project, so it is easy to tell what needs to be contributed.
*Plugin Engine. We will also flesh out a nicer way of classifying plugins and what they do, with interfaces and everything. This will make more sense in the documentation and UML.
*Plugin repositories. Plugins should be obtainable and managed in the same way that Ubuntu manages packages with apt-get.
*Hopefully, and although this is not a priority, we will write all interface code in a language that can be interpreted by any user-interface package, for example XAML or XUL. This will allow for very easing porting / extensibility of UIs.
More details will be posted, and as always check the SVN repository for new code. I promise, the next commit will change the SVN repository to look like it should, with a trunk, branches, and tags.
Augie (0 comments)
Website Update Complete
Wed, 18 Oct 2006 07:29:41 GMT
Wednesdays are no longer the busiest day of the week because of college work, but because of GibPhone as well. The full, functional implementation of this website is complete. Obviously it is aesthetically pleasing BUT it is XHTML 1.1 compliant as well. Hopefully, this will add to the advancement of this project very much into the future... (0 comments)
What to expect in 1.0
Fri, 15 Sep 2006 22:00:09 GMT
Some more changes have been made to the GibPhone development tree and it has been decided what GibPhone 1.0. Here are a few things that you can expect:
-GibPhone 1.0 will not be released with a plugin set. A lot of our time up until now has been spent on plugin development when we should really perfect the core first. For this reason GibPhone 1.0 will be released only as a core.
-The core will use XML to save the list of contacts. The schema will be enforced and thoroughly documented.
-The core will have a central event system and will have support through the extension of interfaces (the latter may be bumped up to a later version because of difficulty).
-The core will be able to load and unload plugins at will.
Expect the roadmap to be published shortly once we get our web developer to do it. (0 comments)
-GibPhone 1.0 will not be released with a plugin set. A lot of our time up until now has been spent on plugin development when we should really perfect the core first. For this reason GibPhone 1.0 will be released only as a core.
-The core will use XML to save the list of contacts. The schema will be enforced and thoroughly documented.
-The core will have a central event system and will have support through the extension of interfaces (the latter may be bumped up to a later version because of difficulty).
-The core will be able to load and unload plugins at will.
Expect the roadmap to be published shortly once we get our web developer to do it. (0 comments)
GibPhone feature set frozen.
Thu, 17 Aug 2006 00:52:56 GMT
Ahoy! A unilateral decision has been made to freeze the current feature set. Any and all feature requests will be bumped up to the next major release. Until then, Gibphone is set at this:
The AIM client will have basic support (everything we currently have an interface for should be supported, and some other things should be supported as well, details to come)
The GibPhone Speex client will have basic support.
Any issues with menus and form generation will be entirely ironed out until it becomes a science.
Anything already in the GibPhone tracker will be completed.
The idea is that GibPhone should be preferable to the AIM client in every way. It should be clear that it is poised to become a very powerful VoIP application. It should also be easily extensible and plugin development should be obvious.
I will keep searching for "micro" solutions to the current plugin set we have now, as I am confident that I can do them better, and I'm going to see if James can work on solidifying the Core APIs and their documentation.
Augie (0 comments)
The AIM client will have basic support (everything we currently have an interface for should be supported, and some other things should be supported as well, details to come)
The GibPhone Speex client will have basic support.
Any issues with menus and form generation will be entirely ironed out until it becomes a science.
Anything already in the GibPhone tracker will be completed.
The idea is that GibPhone should be preferable to the AIM client in every way. It should be clear that it is poised to become a very powerful VoIP application. It should also be easily extensible and plugin development should be obvious.
I will keep searching for "micro" solutions to the current plugin set we have now, as I am confident that I can do them better, and I'm going to see if James can work on solidifying the Core APIs and their documentation.
Augie (0 comments)
We are still here
Wed, 12 Jul 2006 15:07:16 GMT
I know its been a while, but I just want everyone to know that we are still here. We are currently working to make Gibphone actually work, we are tired of releaseing buggy Gibphones, it seems like we are getting closer to a release, but at the moment I cannot give an estimate, one thing this release will have is a setup wizard, to easily set up your accounts for your first time run. I realized that the current method was confusing and unintuitive so we are making it better. Alot of the stuff is already done in the SVN, although not the wizard yet. If you want to stay up to date, I would suggest you check it out.
-James
Developer (0 comments)
-James
Developer (0 comments)
nCode and Speex.NET moved
Tue, 20 Jun 2006 22:17:15 GMT
These folders now reside in the nCode project, also here on sourceforge. We figured that Speex belonged more with the nCode project than with gibphone, which is why it has left as well.
Using the svnadmin dump and dumpfilter, the Gibphone SVN no longer contains any record of those folders, and the revision numbers have changed (although I asked it not to do that). This means that updating Gibphone's SVN will require a fresh checkout, as attempting to update revision 238 will cause an error in TortoiseSVN, since it will not believe a revision 238 exists. I am not sure if other clients have this, but just to be on the safe side, a clean checkout is recommended.
In the end, here is how the project folders were divided:
nNTP, nSDP, nSIP (and old SDP.NET and SIP.NET) -> nsip
nCode, Speex.NET -> ncode
GPCore, noscar -> gibphone
-Marc (0 comments)
Using the svnadmin dump and dumpfilter, the Gibphone SVN no longer contains any record of those folders, and the revision numbers have changed (although I asked it not to do that). This means that updating Gibphone's SVN will require a fresh checkout, as attempting to update revision 238 will cause an error in TortoiseSVN, since it will not believe a revision 238 exists. I am not sure if other clients have this, but just to be on the safe side, a clean checkout is recommended.
In the end, here is how the project folders were divided:
nNTP, nSDP, nSIP (and old SDP.NET and SIP.NET) -> nsip
nCode, Speex.NET -> ncode
GPCore, noscar -> gibphone
-Marc (0 comments)
nSIP and nSDP Moved
Sat, 10 Jun 2006 03:04:11 GMT
Recently, we took over the nSIP project after years of inactivity. All of our current nSIP and nSDP code and trackers have been moved over to that project site (http://sourceforge.net/projects/nsip). Everything involving nSIP or nSDP will also cease to be updated on the GibPhone SVN repository, however we will leave what is currently there for archival purposes. All new code should be checked out from nSIP's SVN repository.
Hopefully moving nSIP and nSDP allows us to better manage the two projects and present them to you in a better fashion. As always, feedback is much appreciated, so don't hesistate to speak your mind.
Oh, one more note. Recently, we have had the pleasure of extended correspondence with somebody who is very interested in developing their own VoIP application and wanted our advice and guidance. So far, it has been a wonderful learning experience for all parties involved and it makes us feel great to know that other people are interested in similar projects. It also helps us improve ours. Please, if you think there's something we should know about or if you want to see if we can help you with something, don't hesitate to drop us an email. (0 comments)
Hopefully moving nSIP and nSDP allows us to better manage the two projects and present them to you in a better fashion. As always, feedback is much appreciated, so don't hesistate to speak your mind.
Oh, one more note. Recently, we have had the pleasure of extended correspondence with somebody who is very interested in developing their own VoIP application and wanted our advice and guidance. So far, it has been a wonderful learning experience for all parties involved and it makes us feel great to know that other people are interested in similar projects. It also helps us improve ours. Please, if you think there's something we should know about or if you want to see if we can help you with something, don't hesitate to drop us an email. (0 comments)
Gibphone Version 0.7
Fri, 19 May 2006 02:35:23 GMT
This update is long running and pretty big. For one thing, IProtocol has been reworked and refactored into many different smaller interfaces. So that an IProtocol developer can cuztomize exactly what they need. Also there are a few new classes for call functions: Sound (capture and playback) IVocoder(encoding and decoding) , INetworkProtocol(sending and recieving data) and IPhone (the parent of all these functions). The IPhone deals with telling each of the other things what to do, there is an abstract implementation of each of these interfaces that deals with the basic stuff.
Another thing that that changed is the way events are thrown between classes. Its now easier and less prone to typographical errors. Another new class called Event has two methods called Register and Fire. A CoreEventListener Registers a certain delegate, it gets put in its invocation list and when the fire method is called each delegate in the fire method is invoked. There is one of these Event objects in static classes with the same name as the interface it belongs to without the 'I'.
Another change is an increase in the extensibility of features. There is now a GPMethodAttribute that can be put on methods in an interface and for each method with the attribute a menu item is created so new features implemented in an interface will automatically be available. Even state based methods like sign on/sign off.
Finally a bunch of interface changes and some cleaning up.
Like I said a big update.
-James (0 comments)
Another thing that that changed is the way events are thrown between classes. Its now easier and less prone to typographical errors. Another new class called Event has two methods called Register and Fire. A CoreEventListener Registers a certain delegate, it gets put in its invocation list and when the fire method is called each delegate in the fire method is invoked. There is one of these Event objects in static classes with the same name as the interface it belongs to without the 'I'.
Another change is an increase in the extensibility of features. There is now a GPMethodAttribute that can be put on methods in an interface and for each method with the attribute a menu item is created so new features implemented in an interface will automatically be available. Even state based methods like sign on/sign off.
Finally a bunch of interface changes and some cleaning up.
Like I said a big update.
-James (0 comments)
SDP.NET updated to version 1.1
Thu, 18 May 2006 03:35:51 GMT
Tonight I uploaded the source and binaries for version 1.1, which is actually much more than just an incremental release. Most notable, it is possible to parse existing session descriptions with ease. I have also included some constants to make RTP/AVP programming easier and the API looks a lot more like JAIN-SIP's SDP library. I did this because they had some ideas that I really liked regarding design, but I still think that our design and code is better.
Please download SDP.NET and try it out. Let us know what you think! (0 comments)
Please download SDP.NET and try it out. Let us know what you think! (0 comments)
SDP.NET Version 1.0!
Sat, 13 May 2006 20:14:23 GMT
We haven't announced it ever before or even talked about it amongst ourselves, but somehow we released SDP.NET last night. Currently it should be able to create valid session descriptions and convert them to string form for sending. The next release, which will come in two or three days will include the parsing of session descriptions from strings into the data structures. Some attributes that are supported by the IANA will also be included.
This class library was coded in two nights, so I'm sure there are many bugs (it's my fault, because I wrote all the code for this one). Please leave feedback either in the forums or the tracker, or even shoot me an email. We'd love to hear what you think. (0 comments)
This class library was coded in two nights, so I'm sure there are many bugs (it's my fault, because I wrote all the code for this one). Please leave feedback either in the forums or the tracker, or even shoot me an email. We'd love to hear what you think. (0 comments)
