[Foundation] Growing Concerns for Client Developers
temas
temas at box5.net
Thu Oct 4 12:51:09 CDT 2001
Well I'd rather move the forms related discussion over to the forms jig
where I'll post my feelings soon (even though that was the push over the
edge for this email). Got caught up in a meeting before I could post my
forms thoughts.
As to the other replies in the thread; I guess my current line of
thought really sticks the most with the jabber:client, as used for chat
style IM, namespace. I would hope to see more namespaces evolve, and
those would obviously be treated differently and have different client
namespaces, but jabber:client has certain goals. Maybe this is even
something that needs to be proposed/done for new namespaces, a JEP
describing the goals of the namespace, end point details, and other
worthy notes. Something like this for all the current major default
namespaces would surely be helpful.
--temas
On Thu, 2001-10-04 at 12:19, jon hag wrote:
I totally agree that we could really simplify client development by
placing the XSLT processes on the server, and by preferring simple
XML parsers for the client.
But is it possible to provide standard forms in this XML client
set? and if not, all these independent clients will eventually
start building out their own forms support and we end up with this
bad scene of client clash, which will hurt the whole Jabber
community.
Jabber really needs a firm grassroots handholding on the client
side, this will pay off huge long term. I am all for text based
command line clients, but if thats all we do, then we end up with
linux sysadmins using Jabber and everyone else using MSN/AOL/Yahoo.
Some sort of strict XML schema wrapper for client UIs would be cool,
with poss hooks for xForms/xHtml, server side handlers for remote
includes/schema_fragment_lookups/fragment_cache/etc.
At the same time, we don't need full web browser funtionality (at
like 20MB a pop), which raises the point of how a Jabber client is
unique from a web browser (philosophically) ?
-john
>From: temas
>Reply-To: members at jabber.org
>To: members at jabber.org
>Subject: [Foundation] Growing Concerns for Client Developers
>Date: 04 Oct 2001 11:06:41 -0500
>
>One of the original goals of Jabber was to keep the clients simple,
so
>that we could have more clients on more platforms. Some recent
trends
>in the amount of information and requirements that are being pushed
on
>to the client are beginning to scare me. Some of the ideas that are
>starting to foster in the JIGs would require clients to implement
heavy
>protocol pieces and engines such as XPath and XSLT. While both of
these
>technologies are great, I feel they are better left to the server
side
>of things. Clients should only need to understand simple XML
parsing,
>namespaces (although that needs to be fixed all over the place),
and the
>XMLStreams protocol. We currently have no guidelines or suggestions
for
>how a JIG should form it's technology, especially with relation to
>clients. Maybe we need an informational JEP outlining the
principles of
>Jabber XML and client simplicity with regards to protocol handling?
I
>think this could greatly benefit newcomers in general and our
protocol
>designers.
>
>--temas
>
>P.S. - Yes I am indirectly implying I would work on this =)
><< attach3 >>
____________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com
_______________________________________________ Members mailing list
Members at jabber.org http://mailman.jabber.org/listinfo/members
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
Url : http://jabber.org/pipermail/members/attachments/20011004/bb0403a6/attachment.pgp
More information about the Members
mailing list