[Foundation] Growing Concerns for Client Developers

[temas]

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