Input regarding Pueblo-replacing protocols.

Submitted by Cheetah on Sat, 2011-08-13 16:52

Huge disclaimer to start: Nothing may come of this.

If you can live with that, let me add a redeeming thingy: If I don't actually work on this at all, at least the data will be available for future reference.

So are you ready? Okay.. Given an implementation of a new protocol to do the sort of thing Pueblo does, but isn't Pueblo, what sort of things would you require? What sort of things would you suggest avoiding?

Please note, I'm mainly talking about functionality here, not implementation details. If your suggestion contains words such as 'XML', you'd better be actively, personally concerned with the implementation of such a protocol, as a client dev of a codebase dev ;)

Of course, if you are a dev of either kind, I'll gladly listen to concerns about implementation, especially if they'd be deal breakers for support. Beyond that that, I'm looking for softcoders, end users and similar points of view. I have some vague ideas bubbling in my head, but I need to hear the sort of thing I couldn't come up with and, on the other hand, confirmation that the sort of thing I think of isn't stupid ;)

List of some things I have so far:

  • Minimal requirements for specific 'tag' support in clients and graceful degradation.
  • Availability of metadata
  • Flexible security model, suitable for calling from mortal code
  • Extensibility of the protocol
  • Extended colors
  • Potential for clickable links (browser or command)
  • Potential for linking media
  • Potential for context menus
  • Should be easy to use from softcode
  • Should be optional, like Pueblo is now, and should be able to add on to current client and server codebases.

Things that have been requested but are outside the scope of the protocol:

  • Unicode support
  • Negotiation of capabilities outside of the protocol (such as extended ansi or character encoding)