Handling User Input (Validation, Limits & Management)

[Tim Durden]

At present, there seems to be very little validation/restrictions in place for user input. Starting this thread to get some ideas of what rules should be in place for the web client, if any. 

Publishing items

@lloydwatkin: max stanza size is 64k.

1. Will stanzas be split (e.g. if I post a message beyond 64k, should my message still be published?)
   
2. Should I be restricted to how much text I can enter (e.g. Facebook max limit: 63,206 chars)?
   
3. If I post a message over a certain length, should I see a 'Read More...' link within the post to keep things tidy. Beyond that, should I see 'Read More...' after a certain number of chars if the post is really long (say I posted a research paper).

Channels

• Channel title?
  
• Channel description?
  

Preferences

• E-mail address field.

Find Channels/Posts

• Search field

[Simon Tennant]

It's excellent that you are looking at all the validation issues. Comments inline:

On 16 May 2013 19:05, Tim Durden <tim.d...@surevine.com> wrote:

At present, there seems to be very little validation/restrictions in place for user input. Starting this thread to get some ideas of what rules should be in place for the web client, if any. 

Publishing items

@lloydwatkin: max stanza size is 64k.

1. Will stanzas be split (e.g. if I post a message beyond 64k, should my message still be published?)
   

I would hope that XMPP servers and libraries take care of this splitting. 

1. Should I be restricted to how much text I can enter (e.g. Facebook max limit: 63,206 chars)?
   

Perhaps for the posts node. But then someone might want to keep a blog and need longer posts. So we'd want a per-node/application restriction. Whatever we decide, we need it specified clearly in https://buddycloud.org/wiki/XMPP_XEP#Content_normalization

1. If I post a message over a certain length, should I see a 'Read More...' link within the post to keep things tidy. Beyond that, should I see 'Read More...' after a certain number of chars if the post is really long (say I posted a research paper).
   

A pull request to integrate https://developer.mozilla.org/en-US/demos/detail/paperfold-css/ would help solve this!

 

Channels

• Channel title?
  
• Channel description?
  

Neither of these have restrictions - I was kinda hoping for seeing how they are displayed in different clients and then finding something sensible. Perhaps we should shoot for 256 and 1024 characters respectively.

 

Preferences

• E-mail address field.

Not enforced 

 

Find Channels/Posts

• Search field 

You mean a query length? Abmar says "1024" - don't think it's enforced though.

 

--
You received this message because you are subscribed to the Google Groups "buddycloud-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to buddycloud-de...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
Simon Tennant | buddycloud.com | +49 17 8545 0880 | office hours: goo.gl/tQgxP

[Ashley Ward]

On 22 May 2013, at 12:30, Simon Tennant <si...@buddycloud.com> wrote:

1. Will stanzas be split (e.g. if I post a message beyond 64k, should my message still be published?)
   

I would hope that XMPP servers and libraries take care of this splitting. 

I don't believe that they do. This needs to be done in the client (or in the case of buddycloud, in the http api server)

1. Should I be restricted to how much text I can enter (e.g. Facebook max limit: 63,206 chars)?
   

Perhaps for the posts node. But then someone might want to keep a blog and need longer posts. So we'd want a per-node/application restriction. Whatever we decide, we need it specified clearly in https://buddycloud.org/wiki/XMPP_XEP#Content_normalization

Again, are we not going to hit the problem of maximum stanza size? If people need to post big things then that will need to be done out of band somehow (perhaps via the media api?). Personally though, I think a limit would be acceptable because if somebody is posting a full-on blog in buddy cloud then they're probably using the wrong tool.

--

Ash