Difference between revisions of "Project Proposals"

From XMPP WIKI
Jump to navigation Jump to search
m
 
m
 
Line 1: Line 1:
This page is intended to be a repository of ideas for Jabber-related projects.
This page is intended to be a repository of ideas for XMPP-related projects.


== Servers ==
== Servers ==
* A framework for migrating server data. For example, with an Ejabberd and a Wildfire plugin, one could easily migrate the data from one server to the other. ([[User:Remko|Remko]])
* A framework for migrating server data. For example, with an ejabberd and a Wildfire plugin, one could easily migrate the data from one server to the other. ([[User:Remko|Remko]])
* A lightweight Jabber daemon that acts as a regular jabber server on the client side, but uses [http://xmpp.org/extensions/xep-0174.html Serverless Messaging] on the  server side. Running this daemon on a local machine allows any Jabber client to support link local messaging by connecting to the daemon on localhost. ([[User:Remko|Remko]])
* A lightweight XMPP daemon that acts as a regular XMPP server on the client side, but uses [http://xmpp.org/extensions/xep-0174.html Serverless Messaging] on the  server side. Running this daemon on a local machine allows any XMPP clients to support link local messaging by connecting to the daemon on localhost. ([[User:Remko|Remko]])
* A "Server Discovery" feature in each client, so that a never-have-used-Jabber-before user can download/install/launch a Jabber client and create an account from within his software, without having to search the web and ask in forums "what server do I have to use?". ([[User:Nyco|Nyco]])
* A "Server Discovery" feature in each client, so that a never-have-used-XMPP-before user can download/install/launch an XMPP client and create an account from within his software, without having to search the web and ask in forums "what server do I have to use?". ([[User:Nyco|Nyco]])
* [http://www.lucas-nussbaum.net/blog/?p=177 Distributed monitoring of the Jabber network] (was <s>[http://www.lucas-nussbaum.net/blog.php/?2006/06/02/186-non-google-summer-of-code-proposal-distributed-monitoring-of-the-jabber-network Distributed monitoring of the Jabber network]</s>)
* [http://www.lucas-nussbaum.net/blog/?p=177 Distributed monitoring of the Jabber network] (was <s>[http://www.lucas-nussbaum.net/blog.php/?2006/06/02/186-non-google-summer-of-code-proposal-distributed-monitoring-of-the-jabber-network Distributed monitoring of the Jabber network]</s>)
* A system working somewhat like rooms, with forever-logged messages, and presence too: those "rooms" would be used for meetings. They would have three user lists, a date+time field, a location (real or virtual), a topic big enough to contain a small description of the program of the meeting, and a public area where users would post comments ("great, i'll be there!", "sorry people, i'm ill", ...).  The three user lists limit could be extended, but actually the idea is: one list for participants, one for one's that have refused the invitation, and one for the "not sure" ones.  The extension would allow the meeting manager to define more categories in which subdivide the users; the categories could be thinked as just "flags" in front of each user, instead of those big userlist boxes.  A post-meeting photo-album system could be nice, too (asking too much, eh? ;).
* A system working somewhat like rooms, with forever-logged messages, and presence too: those "rooms" would be used for meetings. They would have three user lists, a date+time field, a location (real or virtual), a topic big enough to contain a small description of the program of the meeting, and a public area where users would post comments ("great, i'll be there!", "sorry people, i'm ill", ...).  The three user lists limit could be extended, but actually the idea is: one list for participants, one for one's that have refused the invitation, and one for the "not sure" ones.  The extension would allow the meeting manager to define more categories in which subdivide the users; the categories could be thinked as just "flags" in front of each user, instead of those big userlist boxes.  A post-meeting photo-album system could be nice, too (asking too much, eh? ;).
* A option that the server could publish its registered users and group them. Even to show the online-status would be great.
* A option that the server could publish its registered users and group them. Even to show the online-status would be great.
* Use of tags to group members. This is esp. for comercial use where buddylists arn't sufficient.
* Use of tags to group members. This is esp. for comercial use where buddylists arn't sufficient.

Latest revision as of 02:21, 17 December 2020

This page is intended to be a repository of ideas for XMPP-related projects.

Servers

  • A framework for migrating server data. For example, with an ejabberd and a Wildfire plugin, one could easily migrate the data from one server to the other. (Remko)
  • A lightweight XMPP daemon that acts as a regular XMPP server on the client side, but uses Serverless Messaging on the server side. Running this daemon on a local machine allows any XMPP clients to support link local messaging by connecting to the daemon on localhost. (Remko)
  • A "Server Discovery" feature in each client, so that a never-have-used-XMPP-before user can download/install/launch an XMPP client and create an account from within his software, without having to search the web and ask in forums "what server do I have to use?". (Nyco)
  • Distributed monitoring of the Jabber network (was Distributed monitoring of the Jabber network)
  • A system working somewhat like rooms, with forever-logged messages, and presence too: those "rooms" would be used for meetings. They would have three user lists, a date+time field, a location (real or virtual), a topic big enough to contain a small description of the program of the meeting, and a public area where users would post comments ("great, i'll be there!", "sorry people, i'm ill", ...). The three user lists limit could be extended, but actually the idea is: one list for participants, one for one's that have refused the invitation, and one for the "not sure" ones. The extension would allow the meeting manager to define more categories in which subdivide the users; the categories could be thinked as just "flags" in front of each user, instead of those big userlist boxes. A post-meeting photo-album system could be nice, too (asking too much, eh? ;).
  • A option that the server could publish its registered users and group them. Even to show the online-status would be great.
  • Use of tags to group members. This is esp. for comercial use where buddylists arn't sufficient.