Okay. Well, I wanted to give a small introduction to ScalableOgo, which is a groupware server written on an object of C.

And, oops, first a bit about token-groupware-org. This is a larger project which is, well, more like a framework for building groupware servers. Pretty much like Mostep is a framework for building GUI applications.

So, we are focusing on building reusable objects for building such servers. Because the requirements for groupware servers are pretty different. So, there's not just one groupware server which fits all, but you usually want to have different kinds of groupware 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 RSSP tweeters or calendaring clients and the servers.

And, currently we have two implementations of groupware servers. The first one is OpenGroupware, the regular cat OpenGroupware. It's for smaller work groups and has a pretty complex functionality.

And, so ScalableOgo, 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, OpenGroupware is not just for building those two implementations,

but we really want to bring forward groupware standards as well. Like, for example, Calendar and GroupMap. And, we also do not want to reinvent the software. For example, we are not building any IP software on email servers, stuff like that,

because they are really great projects which are already existing. For example, Skyworks for mail servers or Korea for mail servers. It doesn't really make any sense to replace those. Do you have any kind of integration or something like that?

Do you have any kind of integration or something like that? Yeah, mail attacks are integrated into the email system usually, so it's not really related to the groupware part, but it fits into a larger picture. As I said, we also go to groupware standards.

We want to connect with clients. So, we do not want to be a web-groupware project. And, of course, we want to use completely free software, so we do not use any non-free software in building implementations, whether it's on GPR or on their GPR.

So, to get back to scale order, it's a bit difficult to explain, because especially end users do not understand why different approaches are necessary. For example, chat logo has a lot of functionality,

and 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, a scalable 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 a scalable server. So, what does scalable order do? It's really based on the standard stuff.

So, for email, of course, we use IMAP400, and we just reuse existing mail servers, and the address book and the calendar, which are integrated, are completely based on iCalendar and vCard. So, we actually store the data in iCalendar and vCard, so there's no mismatch between native clients

or open source native clients in the server, and it's also very simple. For example, in the pet open book fair, you can have records which are really interconnected. For example, if you have a company contact, you can assign those company records

or the 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 joins between the different tables. But it's not possible in scalable order. In scalable order, a contact is always on its own.

It's just the vCard which is stored in the server. So it's very simple and very fast to retrieve and to store, but it doesn't allow those complex links between the object. As I said, a common problem in group fair is that if a group fair provides more functionality,

like, for example, open group fair, the native clients usually don't support that. So, this is why many group fair 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 scalable order because it just uses the same thing. About history, the scalable order was initially developed for a large French ministry which had about 60,000 users which were to be supplied using that group fair solution.

And they had three basic requirements. First, of course, it would need to be scalable because they wanted to host it on a small cluster, a single small cluster in a central location. So they didn't have a thousand group fair servers, but just one.

They wanted to support native clients, Mozilla native clients, Sunbird and Thunderbird, because in France they wanted to replace 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, well, scalable order was developed to meet all of those requirements. First, scalability.

As I said, that's a very complex topic, but one thing is that a regular database-based group fair service like open group fairs and old ones or e-group fairs, I think about a hundred more, they usually have a single tables, database tables,

for example, an events table where all the events are stored, and all events of the system are stored in that single table. And 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. And so scalable over this is solved because there's a middleware scalable over 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 class machines.

Then as I mentioned before, it draws raw iCalender and vCard. So it just takes, for example, if Sunbird writes an event into the server, it just takes the iCalender and stores that as it gets the event. So it's very fast operation, it's just a single update in 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 iCalender files in the database, you can't use an SQL to have queries on them.

So for example, if you want to show a week of events, you would need to parse each iCalender file. Well, that's too slow. So we have a separate table, which extracts the core information from these files, like start time, end time. And it's stored in an additional database table

for task queries in the web interface. So the web interface can say, give me the point of the sweep. 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 that'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, a rate one, something like that,

which ensures integrity because it's the important information. Whereas the index tables, they can be reconstructed on the content. So you can place them on volatile storage, like 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, now third item, if you don't use the web interface at all, but a native client, they just retrieve

those pre-rendered iCalendar or vCard files. So it's not like in other rootware servers that the iCalendar or vCards are deconstructed into database fields and need to be reconstructed to the iCalendar file on retrieval. We just store them as a can and we just need to pull them out of the database

and send to the client, which is very, very fast. Native clients, our approach was to push open standards. So actually we started out with GroupDef, which is not really a standard, but more like a convention we found

with the KDE developers in 2004, I think. In the meantime, we have Kaldor, which is now an official standard. It's an RFC for something. I don't know the exact code, but it's a real Internet standard and it's widely deployed, scanning a lot of momentum. For example, Google and Yahoo also support Kaldor now.

Kaldor is in the works. It's also going to be a regular RFC. So we are very close and finally having real standards for GroupDef. And those standards are also supported by Scalable Orgo.

Actually, we extend some clients, the open source clients, which is very well, do not support standards very well, unfortunately. So the Calif implementations in Mozilla, for example, do not provide all the necessary features. The Atlas book cannot do the contact and stuff like that. It's not possible to write.

I think in the regular, I don't know. However, we have plug-ins for those clients which add some listing functionality. For example, we have a card dev address book for the Thunderbird address book. And there are also extensions for the Kaldor connector in Mozilla.

So it's actually the primary client for Scalable Orgo. It works really well. Then we have a Funnambool plug-in. Funnambool is a Java server which is used to synchronize mobile devices, like mobile telephones.

And we have a plug-in which directly connects the database. Because the database stores the iCalm NP card files, you can just push that into the Funnambool. Well, because we support those standards, especially Kaldor. Of course, you can use the iCalm for accessing the server.

You can even use a regular web dev client to browse the collections and stuff like that, which is also quite nice. The web interface, as I said, it was a requirement that they wanted to have the web interface that 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. It's just because the Mozilla interface looks so ugly. It's also very scalable, because we do a lot of HTTP transactions inside the web interface.

HTTP is actually a very scalable code. The code has a lot of features to support scalability. One is the ETag. The ETag says whether the 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. So if the browser tries to re-get the same page, it just checks whether the token changed.

If it didn't change, it 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, or 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 even need to be bothered with multiple users.

The thing where this is working best is emails, because emails in an IOP server can be changed. It's always the same. If you would change an email in an IOP server, it would get assigned a new ID.

So if you have an ID in the IOP 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 it's retrieved at 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, some buzzword stuff. So scalable-ogo is REST, which is basically another word for HTTP, in my opinion, because, well, it's this dialogue on how to write HTTP services,

and scalable-ogo is implementing or build around those web protocols, which use the standard HTTP words, put, get, delete, to read and write the icon,

and now we cut files. So for example, to see the icon in the web browser, you can just enter the URL to the icon file, and instead of adding a .html, you will add a .ics, and then you get the icon in the presentation,

directly pulled out of the database. That's pretty nice. Well, even for email, you can, even the web interface is built around that REST principle, or that web. hierarchy. So you can actually use scalable-ogo as an IMAP HTTP gateway.

For example, if you have a user, it could be the login name in the IMAP server, you can traverse the IMAP folder hierarchy and get to the email ID, like 123 email. If you retweet that using an HTTP library or a web browser,

or whatever you want to do, you actually get the MIME, the MIME 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 MIME 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 MIME structure, and all the work is done by the IMAP server, so it's just a gateway. That's also how the web interface shows images.

If you bring up the HTML page representing that email, it's something like wanttofeed.html, and that HTML page actually refers 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 with IMAP, which can be quite complex. So, where are we?

Actually, we are very close to a 1.0 release, so it's 1.0 release candidate 9 was released last week. Actually, it's in production at really large customer sites. 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 deployed. 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's a release like RC9, they push the state to the Subversion server so that we have a proper release history and a central 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 support for more native clients, and that's something I said before, because the situation in 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 to support standards.

Well, code internals, an object is written in object of C, so it's a real compiled code, and you get a real demon out of that, not some virtual machine file which you need to run and something which takes 10 gigabytes of memory and just works a little hard.

So, well, object of C, some may not know, it's really a 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 password compliant thanks to the iPhone, because the iPhone, I think, brings a lot of developers to object of C, because all the software written on that was written in object of C, and so it's quite great. And I try to bring up a diagram of how it all fits together.

It's basically the object of C one time, which is coming with a new compiler. Then we have the GNU step-based library, which is used by Scala or Go, and for open root 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 Soapy application server. This is doing a lot of things. Well, 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 Go and open root there, for example, generating iCalender files, or parsing them, drawing deep views in HTML, and all the stuff, and it's a lot of stuff in Soapy, and I would say it's about 70 percent of scalable Go,

maybe even a bit more, because we use such a lot of 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 fast.

Yeah, how you can reach us? Well, of course, using the website that's scalable.org, or open root there org, and the mailing is for scalable.org's SOHO at open root there org, and it's open to everyone,

everyone can subscribe, and join us, and comment, and help us test, whatever. That's important. Questions? What's the standards of packaging of the SOAP framework, and of the PR component of the scalable open, because I harped myself for you to go installing the other OGO server,

and for the compliance between the libraries of the SOAP 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 other young packages for Red Hat,

but I don't know about Debian. So I'm not sure. But yes, there's packaging for Red Hat, or RPNs, and that's actively maintained by Ingo, so I think they are using the same packages for their customer deployments, or it's supposed to work.

Yeah, I remember. Actually, it's not that easy to build from source code, because a scalable OGO patches a few things of Sophie. It's mostly because we use those different foundation libraries.

Could you discuss, what is the role of the foundation? Is it disappearing gradually? Well, it's clearly in a better library, because I've worked on it. Well, the foundation hasn't really developed any further. I mean, it's stable, it does what it does,

and we do not put a lot of work into that, to port it over to the SOAP base, but I think maybe it's a sweet end. Sebastian is very active in that. Maybe he can convince Richard to work a bit more. The big effort now is on the scalable. Not anymore on the OGO.

The scalable OGO is already using the SOAP base library. The big effort now on development goes on the left side. Exactly. We basically would like to replace this with the SOAP base library. The major advantage for open group here would be that the SOAP base library has better Unicode handling.

So the foundation only really does ESOLite in one. So open group here is a bit restricted with foreign languages. For example, in Czech or Polish. 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 the SOAP base over time, but that mostly depends on the people who work on it. My motivation is pretty low on doing that, because it works for me.

How likely is the community? Well, how? I don't know. There's some mailing. I don't know. Most of the work, my experience with groupware services, open group and scalable, is that a lot of people are not interested in doing that.

So it's usually a small circle of developers, which are also businesses in that domain. It's not like there's some student which likes groupware services, because it's a business application, basically, and it's very hard to build a community around that.

But I think we have about 10 to 20 guys or something like that which are actively involved. Can you tell us about the current status of CalDev compatibility with different clients? Is it 100% compatible with iCalDev?

CalDev doesn't implement all of CalDev. In fact, I think no server can support all of CalDev, because it's quite complex. Most groupware servers actually implement a subset which is required to host Apple iCalP.

So we get the free business? Free business is supported, actually. That's also an add-on for Mozilla. Mozilla is extended for free business functionality, and those are scalable. So it's not too bad. Well, my opinion is that people should rather use GroupDev,

because it's much simpler, and you can actually implement all of that. And CalDev can be pretty complex, because you need to implement position resend. There's a whole bunch of stuff which is connected to that. But I'm doing CalDev talk tomorrow, so I can come tomorrow.

So the database is not being processed, and the database is not being processed on server-by-server. Is that still used in the online? Yeah. Any plans for the DLP?

No. Actually, we are not using a lot of that in ScalableOgo, because the GDR, it's an object-mapping framework for those who don't know it, where you can map database records to objects, and that's too slow for what we are doing there at that scale.

So we are only using the adapter level. It's like JDBC or something like that. That's what we use in ScalableOgo, 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's PostgreSQL R. I think we have a lot more adapters in GDR1 of Soapy than in GDR2. I brought a SQLite one, a MySQL one. What else do we have? We have a Cypress one.

I think pretty much any database. Font-based. Font-based. That's given by an instruction layer on the Soap app, right? Yes, this is actually multiple libraries. So there's reusable code, and the GL library is also, or GL1 library, is part of Soapy.

Technically, it's a GDL database library. We just imported a previous version into the Soapy application server, which was working for us. And Glooster is continuing the development of the Glooster database library separately from that.

So we're a bit like the foundation situation. We have a pretty stable GL1 library in here with a lot of connectors and stuff like that very well tested. And could possibly change to GDL2, but it doesn't buy us a lot at this moment

because the stuff which is new in GL2, 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 GL1

that stood away from the original version. Was it more speed-like modifications that we started then, or more than normal in the GDL1? It's actually a modified GDL1, which we did some stuff, which makes it faster or more reliable.

For example, our version doesn't throw exceptions. We remove all exceptions, but return just proper error codes because exceptions in Objective-C are always more efficient. I don't know. I don't trust that.

Is there a plan to make authentication against cameras on the open world server? The regular one? Yes, the regular one. I know that there are also some deployments which actually use Active Directory as an ADAP service,

but I'm not a Kerberos expert. I know very little about that. On the open-group-to-world side, development is still going on, or now it's going... Well, for example, the bus then is working on the groupset-based port, but functionality-wise,

there isn't a lot happening more than... Because the web interface of the open-group is three years later than it is now by users. Well, it's mostly a matter of time because the people I know are fine with that interface,

but a basic plan for me was using the scalable open-group interface and something which is called a side-store server in open-group. The side-store server does the iCalender and vCard stuff for open-group there, so it maps things to iCalender and vCard,

and that's pretty similar to what the scalable overall user interface does, so it could possibly reuse the interface and the other ones. I would like to have some time to try the scalable because the open-group-to-world, the integration with the iCalender and the vCard is... Well, certainly can be improved, that's true.

Actually, I am also doing a Java project with the open-group there. So I actually implemented the whole stack from the fed open-group in Java, so there's actually an OBOJ now, but it only has a customized user interface for one specific client,

but it uses exactly the same database, and it's also a modern user interface, but it's really tired, and it's an internal information system for a pharmacy chamber, so they have pretty specific requirements, but maybe it evolves into a new open-group there. The integration with proprietary software

is allowed, is the question? Of open-group there? Yeah, of course. Well, a lot of stuff is LGPL. My first question for the next question is, can I make some question about proprietary integration?

Can I ask for open Outlook? Is it integrated, or...? Well, actually I'm working for a company which does an Outlook plugin. There's a new one coming, which is... We used to have an Outlook plugin just for open-group there, which was using an all-important call to talk to the open-group server, and we are just...

In the last three years, we are retargeting that Outlook plugin to use Kaldef and Cartef, so you can actually use that plugin with any server which supports Cartef and Cartef. So, that's in the works, and you have to... And you're going to sync all the calendars of mobile phones and stuff like that,

because it was not compatible before. With mobile phones, you could use Pannable, and it's scalable. It's not even variable. But for open-group here, you could... Actually, it can be a prime, a so-called prime with store and outbox, so you can replace your PST file with that store, and then you can even synchronize all mobile devices with that.

That's true. So, it's much better... Because I remember that the sync was going... You have two stores, basically. The one, which is... Your primary one of the client, and the secondary one, which is given by the plugin. Yeah, yeah, yeah. But was not syncing, because it was pointing to the first one. Yeah. It's mostly a problem of outbox,

because outbox can only sync a so-called default calendar. And to replace a PST file, you need a so-called primary storage provider. And the old plugin could be one. It was not complex enough. The new one? But the new one can be a primary store.

Well, it's reworked completely. It actually uses SQLite as a database, and you can take it as a replacement for the ST file. I had a project in which we used OpenGrouper to substitute completely exchange files. It's not. Yeah. The current plugin, which we are now developing,

doesn't do email yet. So, you would still have to... You have the primary store, which does the calendar and the address box, and then you have the IMAP connector form. So, it's one additional configuration. But we are working on that one. Yeah, the K-point will push it in the real business. Yeah, but it's not different with outbox in the general case.

If you want a set of outbox to use IMAP, you still also get two. Yeah, usually if you have outbox changed, the point is to get rid of it. Yeah. Okay. More questions. Why are you working on the Java version?

Why are you so smart? I was expecting this question. Well, it's business. 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 know what I'm talking about. So, who's next? I think we have a break.