Messages

1

Applications / Re: Open Source on-line spreadsheet

« on: June 28, 2007, 12:00:44 am »

Did you check the latest features added to pbwiki?
They have added spreadsheets to pbwiki using numsum.
Might give us some pointers.

2

Applications / Re: On the Wiki Engine

« on: June 15, 2007, 05:30:59 pm »

Check out the list of wikis based on the programming language used:
http://c2.com/cgi/wiki?WikiEngines

Also some more here:
http://c2.com/cgi/wiki?WikiEngineReviewWikiLists

3

Applications / Re: Open Source on-line spreadsheet

« on: June 15, 2007, 05:20:49 pm »

I just tried Zoho spreadsheet and this is what I will have to say about a hypothetical web spreadsheet (a slight modification of the one I stated few post earlier)
------------------------
This is what I believe in a very abstract way what the spread sheet should simulate.

The online spread sheet is  a table of cells
Each save of the document creates a state or version of the spread sheet.
Each cell can have their own attributes (like color/type of data etc..)
Operations on cells and combination of cells will be based on the attributes of the cell - eg. mathematical functions - which actually make a table into a spread sheet.
----------------------

Any comments?

4

Architecture / Re: Concern with present architecture/platform

« on: June 15, 2007, 05:05:19 pm »

I tried Zimbra and Zoho on the web today.

Zoho is really what openGoo is trying to do though in a much more associated way.
I mean though zoho has a lot of packages/apps they are each isolated from each other. It would be nice if they can remove this separation and bring a single point of entry and view over the entire suite.

Zimbra is still very much behind Zoho in many areas. Their application seems to have started off as email client and now they plan to integrate the web office suite in it.

Try Zoho to get a feeling of the kind of features we can expect and what to ask for.

5

Architecture / Re: Concern with present architecture/platform

« on: June 15, 2007, 03:24:15 pm »

I think there is a big difference in the philosophy of activecollab and opengoo.
Activecollab has married collaboration to a blog whereas opengoo is trying to implement a web office suite.

They are rather remarkably different. I dont think activecollab has any web office application in their software.

The things that look closer to our needs in activecollab is their plan to:
# build richer interface
# plugin support

We can plugin the opengoo apps to activecollab once opengoo is ready.

As for php like I said before as long as we are ready for the future concerns of opegoo anything is fine,  just that the app/product should be future ready and not be a old piece of code in future.

And finally I think opengoo is going to be a web office suite with blogging (like active collab) plugin to it.

6

Applications / Re: Suggested apps for Milestone 1

« on: June 11, 2007, 02:44:27 pm »

As part of the suggested milestones I would suggest we try to start the web office suite alone now.
As part of it tackle:
Stage 1
->Rich Text Processing App

Stage2
->Spreadsheet App

Stage 3
->Presentation App

Suggestions on this will be appreciated.

7

Applications / Re: Open Source on-line spreadsheet

« on: June 11, 2007, 02:40:23 pm »

Could you have brief look at Zimbra and provide us a overview of how Zimbra has gone about it?
I cant because I right now dont have that infrastructure to setup Zimbra.
Thanks in advance

8

Feature requests / Re: Word processor or wiki exporting?

« on: June 07, 2007, 05:29:28 pm »

Excellent. But what do you suggest? Do we use a wiki as "the engine", use FCKEditor and work from there, or start something new from the ground?

Like I said I would prefer if we have a more plugin based architecture. Something which will be common across all the applications running on top of the engine. Wiki as engine is an example, we can choose to rewrite it completely as our own. As for using FCKEditor we should be able to reuse it (mashup up -  I know...) if not completely in its existing form.

That would be neat! But have you tried WikiCalc?

I have tried WikiCalc but its standalone version and not the hosted one.
Yes I would say say that I was thinking in those lines. But frankly I have not been very impressed with it. I found the others like the one from tikiwiki and twiki to be better addressing the needs.
http://doc.tikiwiki.org/tiki-index.php?page=Spreadsheet
http://twiki.org/cgi-bin/view/TWiki/SpreadSheetPlugin

I think it is OK if you would like to mash up at the application level, but lets try and keep the underlying engine(wiki or whatever) separate from them. This will be better because we can always go back and mashup something else at the application layer than at the platform layer. Also this gives us more options and a safer environment to play with.

I will try and explain with an example which is just a very simple one:

Lets say we take a wiki engine as the base layer/core of the system : a simple (or complex depending on what we need) wiki

• Next we plugin FckEditor on it as a rich text editor
• Next we plugin the Twiki spreadsheet on it as a spreadsheet editor
• We include a blog as a plugin again like what we have one on PmWiki or Twiki
• We include a way to load a ppt for showing slides (maybe on a flash based front end)
  
• Again we include a single signon for all of them using a plugin
And all along the user never knows that he or she is actually working on top of a wiki or wiki like engine!

So its fine if we mash things up at the higher level of abstraction but would suggest we have a common, uniform and strong platform to hold together all of them. Because this will glue together and also be the backbone for the rest of the applications. Yet be separate enough not to impact each other.

9

Architecture / Re: Concern with present architecture/platform

« on: June 07, 2007, 04:54:23 pm »

I guess then the ploy should be to look at existing and pick the best of each and provide a way to run them all together under a single banner. - Is this what you mean?

Or better still take an existing open source project and build on it. (Say Zimbra)

10

Architecture / Re: Concern with present architecture/platform

« on: June 07, 2007, 11:50:25 am »

I know its a tough choice when it comes to a project like this. But these are my observations and I might be just not very right. Most of the open source projects on the collaborative front have started with ground up having a unique flavour of their own (be it plone or zimbra). They would have used ideas from other systems no doubt but finally they are independent of each other.

The reason a mashed up environment might make things confusing would be because we don't have a common platform of agreement. The entire product will be split across the applications and each will have its own development cycle with none able to contribute to the other. The start might seem easier and look plausible but later on we might have to redo the whole thing again.

I would prefer something like the ZOHO guys have done. I "assume" they have a common platform on which finally the whole set of applications are running.

Doing what Google does might look easy but do we have that kind of dedicated manpower and resources to make it seamless?  Their philosophy is slightly different. They bought over the entire suite of online office and have given a seamles look to it with its existing set of applications.

I read about the other article about popfly from MS. Well I felt it was like Yahoo pipes.

I would like to start off with design of a simple engine which will be the backbone for the whole suite of applications. This engine would provide the common functionalities that each of these applications need. Much like a wiki engine (not exactly though) with a plugin like architecture for including the rest of the applications. These applications running on top of it will give the user the kind of look and feel which the application requires.

We can start of with only a rich text editor and spreadsheet before getting the rest of the suite up.

I am still not very convinced about the mash up idea right now. It sounds easy but then raising a family of kids from other different families together doesn't seem rosy.
 

11

Applications / Re: Open Source on-line spreadsheet

« on: June 07, 2007, 11:28:42 am »

This is what I believe in a very abstract way what the spread sheet should simulate.

The online spread sheet is  broken down to cells
Each cell is like a wiki page with its own history
Each cell like a wiki page can have their own attributes
Operations on cells and combination of cells will be based on the attributes of the cell

Many wikis already have a spreadsheet plugin. A few examples below
http://doc.tikiwiki.org/tiki-index.php?page=Spreadsheet
http://twiki.org/cgi-bin/view/TWiki/SpreadSheetPlugin

But they are not exactly as feature rich as the other (namely editgrid or google spreadsheets) May be because we dont have a FCKspreadsheet 

12

Feature requests / Re: Word processor or wiki exporting?

« on: June 07, 2007, 11:14:39 am »

I have worked on PmWiki which is pretty simple yet with lot of features.
And someone had provided a FCKEditor on it to give us a WYSIWYG editor on PmWiki.
I have it on my intranet and though the WYSIWYG editor on PmWiki is not the best, it shows that it can be achieved easily.

But I would suggest that we don't get too much drawn into the wiki thing.
The idea here would be to give the user a view with a transparent wiki component to it. Give them the familiar word like view. The only interesting thing would be to make sure that the user gets the to know when and what changes were made and if the document is being use collaboratively then if any simultaneous edits happen the user is dynamically shown the changes being made and a way to recover the edits (with the overwritten)  incase the user would like to keep them.

I know the above lines can be broken up more neatly. Let me know in case I am not clear above. I am able to give only a small idea with what I have setup, used and observed with the 3 years with PmWiki. And compared it with Google Docs since writely came in. I have received comments from so many that they would prefer a google doc like application than a wiki (which is far more feature rich and extensible). I have been recently toying on an idea of implementing spreadsheets on PmWiki.

We can reuse a wiki but in its simplest form with only the following features:
1. History tracking
2. Authentication
3. Simultaneous edits tracking

The trick I have found about the web based office suites is mostly on the user experience end of it. As long as the user finds himself on familiar grounds it is a success.

13

Architecture / Concern with present architecture/platform

« on: June 06, 2007, 11:45:14 am »

I was reading through the architecture in the OpenGoo pages. Part of which I have copied below.
Architecture:
"Current work is being done in Java/JEE, due mainly to the background of the development team.
We aim to develop a system that is:

• Easy to install
• Cross-platform
• Secure
• Open Source
• Easily Extendable

"

I am not sure if the initial team has tried to look at some other viable options to raise the architecture on.
I think if its the above list of items then Ruby/Python may be a much better option than Java. I am not a java expert and neither an expert on Ruby/Python but I would say that Java now is like what C/C++ used to be to Java before wrt to Ruby/Python. I think, for example Python provides a much richer and neater experience for the developer than Java.

Also since a very large team of people will work across the globe on this product the idea would be to decide on a platform which is SIMPLE (yet powerful!) for people to start and continue. The simplicity of the system and platform will allow more people to join the project.

The problem with this architecture platform that is being setup is that it does not consider one very important aspect of a sound software system - MAINTENANCE
The platform and the architecture should be such that it is easy to maintain and easy to modify. The maintainability will ensure that people understand and pick up the work more easily at any stage of the development.

And another aspect which should be considered for OpenGoo would be to ensure that it is completely open source and is open source proof for the future.

By the way under what license is this product going to be released? GNU, MIT, BSD, Mozill etc etc..
And why?

A sound beginning will result in sound execution and finally a sound application.
These are just my suggestions and would greatly appreciate if people comment and add their views on it for OpenGoo.

Thanks.

14

Feature requests / Re: Word processor or wiki exporting?

« on: June 06, 2007, 11:01:59 am »

My idea of a web based word processor would be a WYSIWYG editor on a Wiki.

Now we can have any wiki under it but the editor should be something familiar.
I agree with conrado that a web based document would basically mean collaboration and if collaboration is to be done we must have the history of changes in it. And the best way to track the user changes across a document is a Wiki.

Even the writey/google doc has something very similar. Just that they have hidden the wiki completely out of picture. Any change made to the document can be tracked back like a wiki and the entire document is editable using the WYSIWYG editor. A little more of ajax is sprinkled to the document to make it more realtime than a text based wiki, lie- auto saves, simultaneous edits tracking etc etc...

As for exporting and importing the document to word we already have the famous OpenOffice open document format.

15

Architecture / Re: OpenSAM

« on: June 06, 2007, 10:50:36 am »

I am not sure why we are talking about OpenSAM here. As far as I know the aim of openGoo is to create a open source web office suite. The folks at OpenSam seem to be talking about a open source standard which will enable a collection of different applications to be brought under a single suite. For that matter even ShareOffice is just a collection of applications (iNetOffice, EditGrid, ShareMethods, and salesforce.com) from the partners to provide a suite of document management. They have not created any web office application of their own!
Read more : http://www.readwriteweb.com/archives/shareoffice_launches.php