 Okay. Well, I wanted to give a small introduction to Scalable Ogo, which is a Goopware server written on an object with C. First, a bit about token Goopware org. This is a larger project, which is, well, more like a framework for building Goopware servers, pretty much like no step is framework for building Goay applications. So we are focusing on building reusable objects for building such servers, because the requirements for Goopware servers are pretty different. So there's not just one Goopware server which fits all, but you usually want to have different kinds of Goopware servers. We have a lot of code, a pretty large code base for calendaring and contact management. We have some simple document management stuff. We have a lot of protocol implementations. By protocols, I mean protocols which are used between client applications like RSS feed tweeters or calendaring clients and the servers. And currently we have two implementations of the Goopware server. The first one is OpenGoopware, the regular cat OpenGoopware. It's for smaller work groups and has a pretty complex functionality and the Scalable Ogo, which is a bit newer, was, I think, started in 2004 or something, or 2005. It's a bit refreshed and has a different focus, which I come to soon. Well, again, as I said, OpenGoopware is not just for building those two implementations, but we really want to bring forward Goopware standards as well, like, for example, in Canada and Goopware. And we also do not want to reinvent the software. For example, we are not building any AP software on email servers, stuff like that, because there are really great projects which already exist. For example, SpyroSport, the mayor's service, or Korea's service, doesn't really make any sense to replace those. The email tax is integrated into the email system usually, so it's not really related to the Goopware part, but it fits in a larger picture. As I said, it belongs a bit to Goopware standards. We want to connect to clients. So, we do not want to be a web-coopware program. And, of course, we want to use a digital-free software, so we do not use any non-free software in building the implementations, but it's on GPR and GPR. So, to get back to ScalaAuto, it's a bit difficult to explain, especially end users do not understand why different approaches are necessary. For example, PetAuto has a lot of functionality. It's not really slow, but it's intended for a few hundreds of users at most. So, you can base a lot of CPU on doing complex stuff. In contrast, the ScalaAuto system is designed for hundreds, hundreds of thousands of users. And to do that, you need to take a lot more care about processing power and storage speed and stuff like that, so we really shrunk the functionality to get ScalaAuto started. So, what does ScalaAuto do? It's really based on the standard stuff. For email, of course, we use iMap4 and we just reuse the existing mail servers. And the address book and the calendar, which are integrated are completely based on iCalendar and WeCard. So, we actually store the data in iCalendar and WeCard. So, there's no mismatch between native clients or open-source native clients and the server. And it's also very simple. For example, in the Tet open bootware, you can have records which are really interconnected. For example, if you have company contact, you can assign those company records or employees and stuff like that. And the system maintains the connection between them. But database-wise, this is quite expensive because you need to do the joints between the different tables. It's not possible in ScalaAuto and ScalaAuto and a contact is always on its own. It's just a WeCard which is stored in the server. So, it's very simple to remove and very fast to retrieve and to store, but it doesn't allow those complex links between the objects. But as I said, a common problem in groupware is that if a groupware provides more functionality, like, for example, open groupware, the native clients usually don't support that. So, this is why many groupware projects provide web interfaces because they can do anything they want in the web interface. But native clients like evolution or contact, they're not easily extensible. So, it's hard to add a complex functionality, but they are the perfect fit for ScalaAuto because it just uses the same thing. About the history, ScalaAuto was initially developed for a large French ministry which had about 60,000 users which were to be supplied using that groupware solution. And they had three basic requirements. First, of course, it would need to be scalable because they wanted to host it on a smaller cluster, a single small cluster in a central location so they didn't have a thousand groupware servers, but just one. They wanted to support native clients, Mozilla native clients, Sunbird and Thunderbird because in France they wanted to replace the proprietary clients like Outlook using open source ones. And third, they still wanted to have a web interface but the requirement was that the web interface should look exactly like Thunderbird or Sunbird, like the desktop applications. And ScalaAuto was developed to meet all of those requirements. First, scalability. As I said, it's a very complex topic, but one thing is that regular database-based groupware servers like OpenGroupware, the old one or eGroupware, I think about a hundred more, they usually have a single database table, for example an events table, where all the events are stored, and all events of the system are stored in that single table. Of course, it's fine if you have a million events or something like that, it's fine for a SQL database, but if you have 60,000 users which have maybe 10,000 events each, it doesn't scale anymore because you get tables which are huge. So ScalaAuto is a source where ScalaAuto can distribute the data between different tables, and those tables can even live on different servers. So actually in the French project, we had three backend servers, so you could assign user groups to the servers and the data would be stored on different cluster machines. Then, as I mentioned before, it stores raw ICLN and read cards, it takes, for example, Sunbird writes an event into the server, it just takes the ICLN and stores that as it gets the event. So it's very fast operation, it's just a single update to the database, and to support the web interface, we also have an index over that information. That's necessary because if you just store the ICLN, files in the database, you can use SQL to have queries on them. So for example, if you want to show a week of events, you will need to pass each ICLN in a file, but that's too slow, so we have a separate table which extracts the core information from these files, like start time and time, and it's stored in an additional database table for fast queries in the web interface. So the web interface can say, give me the importance of this week. The next tables can also be split, there can be multiple tables, and they can even live on different database servers than the content tables which stores the payload. So it's very interesting because the content tables don't need to be on a very fast storage, because for example, they could be on a slow rate 1, something like that, which endures integrity because it's the important information. Whereas the index tables, they can be reconstructed on the content, so you can place them on a volatile storage line, a solid status or something. If it breaks, you can just throw it away and rebuild the index from the content tables. So it makes a lot of sense. So it can be more aggressive in optimization on the index tables. Well, the third item, if you don't use the web interface at all, but the native client, they just retrieve those pre-rendered iCleaner or vCard files. So it's not like in other rootware servers that the iCleaner or vCard are deconstructed into a database field and need to be reconstructed to the iCleaner file on retriever. We just store them as they come and we just need to pull them out of the database and send to the client, which is very reference. Native Client's all approach was to push open standards. So actually, we started out with roof.dev, which is not really a standard, it's like a convention we found with the KDE developers in 2004, I think. In the meantime, we have KALDA, which is now an official standard. It's an FC for something, I don't know the exact count, but it's a real internet standard and it's widely deployed with scanning a lot of momentum. For example, Google and Yahoo also support KALDA now. KALDA is in the works. KALDA is also going to be a regular IFC. So we are very close and finally having real standards for who we are. And close standards are also supported by a scalable organ. Actually, we extend some clients, the open source clients, which is very bad, do not support standards very well, unfortunately. So the KALDA implementations in Mozilla, for example, do not provide all the necessary features. The address book cannot do contact and stuff like that. Is not possible to write. I think in the regular, I don't know. However, we have plugins for those clients, which add some listing functionality. For example, we have the KALDA address book for the Thunderbird address book and there are also extensions for the KALDA connector in Mozilla. So it's actually the primary client for a scalable organ. It works really well. Then we have a Funnambore plug-in, which is Funnambore is a Java server which is used to synchronize mobile devices like KALDA and mobile telephones. And we have a plug-in which directly connects the database. Because the database does the iclinical files, you can just push that into the Funnambore. Well, because we support those standards, especially KALDA, of course you can use the iclan for the server. You can even use a regular Web Dev client for all the collections and stuff like that, which is also quite nice. Well, the Web Interface, as I said, it was a requirement that they wanted for the Web Interface that it looks exactly like the native clients. Now, the native Sunbird isn't very beautiful. It's actually quite ugly, but the Web Interface looks exactly like that. So people often ask us why the Web Interface looks so ugly, just because Mozilla Interface looks ugly. It's also very scalable because we do a lot of HTTP checks inside the Web Interface. HTTP is actually a very scalable code that has a lot of features to support scalable HTTP. One is the eTag. The eTag starts with a Web page changed in the meantime. For example, if the browser gets an HTML page, you can send a small token with that, which represents the state of that page. If the browser tries to re-get the same page, it just checks whether the token changed. If it didn't change, you can pull it from its local cache or in memory cache. So it's very fast. The same is true for proxies. Between the actual application server and the browser, you can put a proxy like Squid, there are other proxies. Apache also has a proxy module in that which can cache the information for multiple users. For example, the browser connects the proxy server and the proxy server asks the application just once, and if another user retrieves the same information, it's already in the proxy, so it doesn't need to be bothered with multiple users. And the thing that this is working best is emails because emails in an iMob server can be changed. There's always the same. If you would change an email in an iMob server, it wouldn't get assigned a new ID. So if you have an ID in the iMob server, it never changes what is stored in there. So actually, if an email is rendered by the Web interface, the HTML page of that email which shows that email, it can be cached by the browser locally. So if you retweet that once, and the user looks at the same email a second time, it's already in the browser cache, so it's really nice. Well, that's some bus work stuff. So Scalable Ogo is REST, which is basically another word for HTTP in my opinion because it's a style on how to write HTTP services, and Scalable Ogo is implementing or built around those web protocols which use the standard HTTP words put at the lead to read and write the iCalender and recut files. So for example, to see the iCalender in the web browser, you can just enter the URL to the iCal file and instead of adding a .html, you will add a .ics and then you get the iCalender representation directly pulled off of the database. That's pretty nice. Well, even for email, even the web interface is built around that REST principle or that that hierarchy. So you can actually use Scalable Ogo as an iMap HTTP gateway. For example, if you have a user, it's a login name in the iMap server, you can traverse the iMap folder hierarchy and get to the email ID, like 123 email, if you retrieve that using an HTTP library or a web browser or whatever you want to do, you actually get the line, the line which represents that email and it's even better because the iMap servers do not also have the facility to extract specific parts from such a line mail. For example, if you get a multi-part mail which contains a text and an image, you can actually address the image using a code. For example, that could be the image which is embedded in the MimeStore channel and all the work is done by the iMap server, so it's just a gateway. That's also how the web interface shows the images. If you bring up the HTML page representing that email, it's something like on2feed.html and that HTML page actually represents the part from the iMap server, so it's really fast. It's pretty interesting. I think it's pretty interesting for a lot of different projects as well, just that gateway because it makes it very easy to develop an email client because it's much easier to work with HTTP than the iMap which can be quite comprehensive. So, where are we? Actually, we are very close to a wonderful release, so it's one dot. Our release candidate 9 was released last week. Actually, it's a production at a really large customer side. So, I think in Canada, the guys who do the main development, which is Inverse, they have about three customers each with about 40,000 users. So, it's actually employed. Anyways, the final release will come soon. The development at this time is mostly done by a company called Inverse, which is in Canada, and they only do open source stuff, so they do not sell anything. So, it's not a licensed business or something like that. They are basically a hosting company for large ministries and education facilities in Canada. And well, you can get the code at a monotone repository from Inverse directly or from Subversion. Every time there is a release like RC9, they push the state to the Subversion server so that we have a proper release, history and incentive server. So, actually, the development is going very well. We don't need that much help on the core server, but what we would like to see is more suffered from more native clients. And that's something I said before, the situation and open source clients and open standards is very bad. So, we would really talk to evolution contact developers for improving that, because we are mostly doing or helping with the Mozilla stuff, so this is a primary client, but we would really love to get some people on improving evolution contact with subtle standards. Well, the code internals is written in Objective C, so it's a real compiled code, and you get a real demon out of that, not some virtual machine fire, which you need to run in something which takes 10 gigabytes of memory and just works a lot. So, Objective C is something you may not know that's really part of GCC as well, you compile that, you get a regular binary out of that, and it's very fast, it's optimized, it's not as boring like JAMA, and it's fast but compliant thanks to the iPhone, because the iPhone, I think, brings a lot of developers to Objective C because all the software written on that was written in Objective C, so it's quite great. And I try to bring up the diagram of how it all fits together. It's basically the Objective C one-time, which is coming with a new compiler. Then we have the new step-based library, which is used by Gable, although, and for Open Group there for historical reasons we use a different foundation library, but those foundation libraries contain stuff like string handling or map tables and all the basic stuff. Then we have the SOPE application server. This is doing a lot of things. As the name says, it's an application server, it does all the HTML rendering, but it also contains all the libraries which are used by Scalable, Ogo and Open Group there, for example, generating i-calender files or parsing them, drawing feed views in HTML and all the stuff, it's a lot of stuff in SOPE, and I would say it's about 17% of Scalable, Ogo, maybe even a bit more, because we use such a lot of the shared code. So, well, on top we have the two applications, the one which is more complex and the one which is very light-white and fenced. You can reach us, well, of course, using the website at Scalable, Ogo, or Open Group there, Ogo, and it's a mailing list for Scalable, Ogo, or SOGO at Open Group there, and it's open to everyone, everyone can subscribe, well, and join us and comment and help us test whatever. Yeah, that's about it. Questions? What's the status of the packaging of the SOPE framework and of the VR component of the Scalable? Because I have my cell freeze, I have to go installing the other Ogo server and all the compliance between the libraries of the SOPE framework and all the other components was a mess with Debian. Debian? Debian. I'm not sure they are providing Debian binaries, actually. I know that they provide young packages for Red Hat, but I don't know about Debian. Is there something for Red Hat? Yeah, but yeah, there's packaging for Red Hat, well, on the hands, and that's actively maintained by users. I think they're using the same packages for their customer deployments for it's supposed to work. I don't know. Actually, it's not that easy to build from source code because Scalable, Ogo, attaches a few things of SOPE. It's mostly because we use those different foundation libraries. Could you discuss what is the role of this foundation? Is that disappearing gradually? Well, why are you wondering? It's clearly a better library because I've never worked on it. Well, the foundation isn't really developed any further. I mean, it's stable, and it does what it does, and we do not put a lot of work into that to port it over to Moosa Base, but I think maybe this weekend, Sebastian was very active in that. Maybe he can convince Richard to work a bit more. The Big Apple now is on Scalable. Not anymore on the Ogo. Scalable Ogo is already using Moosa Base library. No, no, no. The Big Apple is now on development. Ogo is on the left side. We basically would like to replace this against a base library. The major advantage for OpenGoogle would be that Moosa Base library has better Unicode than them. So the foundation only really does Isolate in one. So OpenGoogle has a bit restricted with foreign languages, for example, and check, and check for 400. That's the basic advantage. I mean, stability-wise it's done. There are no major bugs in that. So it just works, but I think we will move to Moosa Base over time because it mostly depends on the people who work on it. My motivation is pretty low on doing that because it works for me. How lively is the community? Development? Well, I don't know. There are some mailings. Most of the work is my experience with groupware servers. OpenBook and Scalable Ogo is that a lot of people are not interested in doing that. So it's usually a small circle of developers which are also business in that domain. It's not like there are some students which likes groupware servers because it's a business application basically, and it's very hard to get a little community around that. But I think we are about 10 to 20 guys or something like that which are actively involved. Can you tell us about the current status? Can there be compatibility with different clients? Is it 100% compatible with... Cal? Scalable Ogo doesn't implement all of Cal. In fact, I think no server can support all of Cal because it's quite complex. Most groupware servers actually implement a subset which is required to post Apple icon. So that's... So we get more free business? Free business support eventually. So that's also an add-on for Mozilla. Mozilla is extended for free business functionality with Scalable Ogo. So it's not too bad. But my opinion is that people should rather use GroupDef because it's much simpler and you can actually implement all of that. And CalDef can be pretty complex because you need to implement provisioning as a whole bunch of stuff which is connected to that. But I'm doing CalDef talk tomorrow, so I can talk tomorrow. Yeah. Actually, we are not using a lot of that on Scalable Ogo because the GDR is an object mapping framework for those who don't know it. We can map database records to objects and that's too slow for what we are doing with that scale. So we are only using the adapter that's like JDBC or something like that. That's what we use in Scalable Ogo so it's not mapping stuff. We don't really need any features of GDR2. I was thinking about database backends because actually there are oracle adapters for that which are actively maintained. There are postcards for our I think we have a lot more adapters in GDR1 of Sophie than in GDR2. I've got a simple light one a minestore L1 what else do we have? We have the cybers one I think pretty much any database. Front-based. Let's give a bit of structure on the soapbox I heard. Yes, this is actually multiple libraries. So we use the code and the GDR1 library is part of Sophie but technically the GDR is the Gnuset database library. We just imported a previous version into the Sophie application server which was working for us and Gnuset is continuing the development of the Gnuset database library separately from that. So we built like the foundation situation. We have a pretty stable GDR1 library and here with a lot of connectors and stuff like that. We're well tested and the code possibly probably changed to GDR2 but it doesn't buy us a lot at this moment because the stuff which is new in GDR2 it's not interesting for us because it's all higher level modeling stuff which we do not use. We need to go pretty much down to the database to get the necessary speed. I think there are some things in the GDR1 where it stood the way from the original version and what if you give more speed like modifications and it will start with that and it's more important in the GDR1 library. That's actually a modified GDR1 which we did some stuff which just makes it fast or more reliable. For example our version doesn't throw exceptions. We don't throw all exceptions but return just proper error codes because exceptions in Objective-C are always a little bit fissure. I don't know. I don't trust them. Is there a plan to make a dedication against Kavanos or who were the regular ones? I know but there are also some deployments which actually use Active Directory as the ADIP service and I think but I know Kavanos expert and I know very little about that. On the open group to our site development is still going on or now for well, for example Sebastian is working on the user base port but functionality wise there isn't a lot happening more than what because the web interface of the open group is three years later than the available open but now by users. That's mostly a matter of time because the people I know are fine with web interface but the plan for me was using the scalable Ogu interface and something which was called the site store server does the i-calendar and v-card start for open group back so it maps things to i-calendar and v-card and it's pretty similar to what the scalable Ogu user interface does so it could possibly really use the interface on the other open group. I would like to have some time to try the scalability for the open group for one integration with the i-calendar and the v-card. Certainly that's true. Actually I am also doing a Java project with open group back so I actually implemented the whole stack from the fat open group in Java so there's actually an Ogu JMA but it only has a customized user interface for one specific client but it uses exactly the same data as and it's also a modern user interface but it's really tired to enter the information system for a pharmacy chamber so they have pretty specific requirements but maybe that will involve some tool in open group I don't know. Integration with proprietary software is the loudest question or Open group then? Well but a lot of stuff with LGPL My first question is can I make some question about proprietary integration? Can I ask for OpenGL Outlook? Is it integrated or Well actually I'm working for a company which does an Outlook platform and there's a new one coming which is we used to have an Outlook platform just for open group which was using an old protocol to talk to the open group server and we are just in the last three years we were re-targeting that Outlook platform to use KALDEV so you can actually use that KALDEV with any server which suffers KALDEV and KALDEV so that's in the works And you're going to see all the calendars of mobile phones and stuff like that because it was not compatible before? Mobile phones you could use Panambo on the scale but it's not even very good but for open group here you could use a so-called crime and you store an Outlook so you can replace your PC file to that store and then you can even synchronize mobile devices with that So it's much better Because I remember that the sync was going, you had two stores basically the one which is your primary one of the client and the secondary one which is given by the client but was not syncing and it's mostly a problem of Outlook because Outlook can only sync a so-called default KALDEV and to replace a PC file you need a so-called primary storage wire and the Outlook could be one it was not complex enough but the new one can be a primary store but it's reworked complicated actually you use a SQLite as a database and as a replacement for a PC file I had a project which we used Open Grouper to substitute completely the change file It's a current plugin which we are now developing and it doesn't do email yet so you would still have to get the primary store which does the calendar and the address box and then you have the iMac connector from so it's one additional configuration but we are working on that for you Yeah, the K point would push it in the real business Yeah, but it's not different from Outlook in the general case if you want a set of Outlook to use iMac you still also get two Yeah, if you are allowed to we have this change the point is to get three of you Yeah, more questions Why don't you work on the Java version it's so simple I will just make the new question Well I'm Christmas but because I'm also doing the work in Java I can assure you it's much more awesome to work in Objective C I am I know what I'm talking about Yeah, we are working