Issue 53585 - Client-Server architecture and scope of groupware
Summary: Client-Server architecture and scope of groupware
Status: CLOSED OBSOLETE
Alias: None
Product: groupware
Classification: Unclassified
Component: glow (show other issues)
Version: 680
Hardware: All All
: P3 Trivial with 2 votes (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact: issues@groupware
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-08-21 22:25 UTC by robertharvey
Modified: 2017-05-20 08:51 UTC (History)
1 user (show)

See Also:
Issue Type: ENHANCEMENT
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description robertharvey 2005-08-21 22:25:45 UTC
I've been looking at Glow and think that it won't be a killer-ap as long as it
is standalone.

I'd like to see a client-server architecture so that multiple users can
collaborate in real time, sharing address books, diary, resource planning and
levelling, troubleticket incidents, customer logs and invoicing, appointment
tracking and reminder issuing, whiteboards and bulletin boards and announcement
splash pages, article archiving and boilerplate services. Oh, and chat/VOIP. It
should, as a by-product, include LDAP services to email clients.

I would like to see the ability to connect remotely over the internet (with or
without VPNs).  This implies significant encryption.
Comment 1 atrapose 2005-10-03 19:40:56 UTC
I totally agree.  Some of the proposed features of Glow work toward this, but
without the integration into the main OOo apps there will never be enough user
visibility or developer interest to see those features developed.

There are three main features that I think need to be included in order to draw
users and developers to this project:

1.  A Toolbar / Plugin available in (at least) Writer that will load Glow and
allow the created .ics file to be saved directly into the jar (.swx, etc.) file.

2.  WebDAV support.  In particular the locking features that let you know if
another user is currently editing that file.  When the IM features are finally
built, users should be able to send the current editor a message.

3.  Non-proprietary server collaboration.  I'm quite sure I don't know the best
way of doing this, but here's the idea.  It should be possible to collaborate
with other users without having an administrator install proprietary server
software and make that server available to everyone.  Security reasons aside, if
two people want to collaborate on a project, adding a third person who's initial
involvement is critical will make using a pen and paper easier than using
software.  Ideally, users on the same subnet should be able to detect each other
through a system like Apple's Bonjour, but use of existing common services like
WebDAV or IM (Jabber, AIM) may be easier to impliment.

Comment 2 Marcus 2017-05-20 08:50:54 UTC
product/component is obsolete