XSF Discussion - 2014-03-26

@xmpp is now ready for the XSF marketing team.

(when it's formed up and ready to go)

Protocol question for folks.

I'm writing up a spec for standardising 'form publishing'. This is where you publish a bunch of form templates to pubsub, and other entities can fill them in and publish the result to a node that will then be derived from the node the template is in.

I think we have no mechanism for standardising pubsub node names, am I right?

I think you are right

nothing that I'm aware of. We went as as far as doing a "well known nodes" for Buddycloud.

That is, I'm considering that you could do something like say "Any node of the form urn:xmpp:form:templates:X" is a form of type X, which is published to a node urn:xmpp:form:completed:X.

What you want to do is to mix up the standardisedness (i.e. This is most certainly a form template) with the unstandardisedness (i.e. This is a form template for Bob's Quiz".

What are people's thoughts on this?

are you trying to define a content type with these forms?

(I have a real requirement around this, including multiple vendors interoperating)

simon@imaginator.com: The form is just a xep4 form.

The idea is that a deployment can choose to have whatever templates it chooses.

Seems a bit hacky (potentially dangerous) to me, if I understand you right

MattJ: What's the Right Way of doing it?

That I don't know :)

But you're saying the forms should be discoverable based on just knowing the pubsub service they are hosted on?

Recursively, through disco, yes.

e.g. you disco your home server, find a pubsub service, find the templates on it, and are from that able to work out the corresponding 'completed forms' nodes as well.

It seems ok, but it's quite conceivable that some services treat node names as opaque strings which are user-controlled

What do you mean by that?

The service isn't mandating the node names here, it's a convention to allow discovery.

The best I currently have is that we do urn:xmpp...template#THEIR_FORM_URI.

As the node names for each template form.

And urn:xmpp...completed#THEIR_FORM_URI for the corresponding completed forms.

Which, as far as I can immediately see, works but isn't elegant.

I understand what you want, I think I need to think about it more

I can go ahead and write up the XEP proposal on this basis.

Indeed I'm tempted to, as it seems to meet our Experimental criterion (nott immediately obvious that it's wrong).

But I'd be happier if it was immediately obvious that it's right :)

Kev, I think what you're proposing works, but you might want a form template to provide where it should be posted to.

dwd: Why might you want that?

Kev, that is, a form template node would contain a wrapper element containing metadata including a form destination.

i.e. My use case doesn't require more flexibility than I propose (and you know what my use case is).

Kev, Why would you want to prevent that flexibility?

Layers of abstraction are only good when they're useful?

Yeah, but you're largely making this a dead-end in terms of extensibility, aren't you?

Kev, FWIW I agree with solving this in some way... I know someone who has a similar need and would love a standard protocol for it

dwd: I don't see why.

That is, I can't see what extensibility is prohibited by this.

But I can see that it's considerably more complex.

What is the use-case, btw?

Link Mauve: Someone wants the admins to be able to publish a set of form templates, and for users to be able to fill them in and submit them.

When they have a need to make sure a report.

Ok.

So you have a "Kev turns up for work late" template, and when Edwin notices that I get into work late, he'll find the relevant template in the list his client has found, fill it in, and hit submit. Then someone else is watching the node to take some action.

Kev, It's just a small wrapper element. You can default the target node if you want.

Isn't that call Lotus Notes?

dwd: It adds an amount of non-obvious complexity.

dwd: Now in order to watch for new publishes, an entity needs to first fetch all the templates, to dereference the publish target.

dwd: Then when a new version of a form is published (new item to the template node), you have issues with how to handle the semantics of changing the destination (I assume this is not allowed).

Why don’t you use node metadata for the suggested post node?

So while it's certainly more flexible, I'd like someone to come up with a reason that it's a requirement somewhere before we go making it less suitable for my requirements.

Link Mauve: In what way?

<field var='x-pubsubform#post_node' label='POST Node' type='jid-single'><value>forms@pubsub.kev.tld/kev_turns_up_for_work_late</value></field>

For example.

Or maybe jid-multi.

Link Mauve: Doesn't that then prevent us using a standard pubsub service for this?

Standard PubSub services disallow custom metadata?

I don't think it's part of the spec, no.

Which is not to say it shouldn't be.

AFAIK, there is no standard method of configuring node metadata.

We should probably fix that. Buddycloud will/does need it I think.

Kev, By the way, anyway of sending custom XML stuffs in Swift?

No. Should be trivial to add to the Debug Console. Do you need it?

(Or indeed on anything short of telnet on a Mac)

Sluift.

Or, for that matter, Psi.

Kev, Only as an immediate debuggery aid. I've an Openfire server acting potentially odd, need to isolate the client.

Oh, Psi.

Laura: Hello Colleague!

fippo / Tobias: Do you have thoughts on the above?

potentially

Kev, well..i think the reply target of a form should be in the form, but as you said, this makes it quite unconvienient to subscribe to them. You want an out of form discoverable way, which says "forms that match this pattern (i.e. of type X or have name 'late') or so go to pubsub node foo

Tobias: Can you see a way in which having a simple transform for template->submission node wouldn't work?

template being what? just an empty form?

Yes.

Dave: waves

Kev, how about when forms are supposed to go to different nodes based on the person who requested it?

Do you have such a requirement?

nope...but it doesn't fell far fetched...sure one could say those different people just have to fetch different forms then

That one would be very difficult to solve. You want to provide a different publishing target to every person who requests one.

So you can't embed it in the form, you can't embed it in metadata.

not to everyone but maybe per group...well the service could embed it in the form the moment the user requests the template

but that's way off standard pubsub i think :)

Somewhat.

Kev, so i'd be +1 on you writing a XEP and see what precisely you propose

Does that mean you're not anticipating -1ing it?

My motivation to XEPpify it if the idea's so bad it can't go to Experimental is limited :)

hehe :)

so basically you disco some well known node and ask where forms of template X are supposed to be posted to?

No.

then i've misunderstood you

You disco the pubsub service. It tells you what nodes are there.

Nodes with a well-defined prefix are templates. You query them to get the templates.

To get the publishing form you take the node and s/template/submission/ or something.

Kev, ta for the tip to use Psi. I seem to have more or less duplicated an interesting bug in Openfire. Do we have any contacts for the developers?

Of Psi or Openfire?

Openfire.

the openfire dev was in jdev from time to time

Ah, cool. I'll try to remember to hang about there.

or on twitter @guusdk

Agenda for today (as it stands right now): UPnP Liason Team wiki Website update Hardware

(probably also a twitter related update considering what I saw on twitter last night)

Bear - you are looking at last week's meeting trello :) I'd like to talk about our marketing (encompassing the website today).

I am just happy that i'm awake after only 4 hrs of sleep

Simon: sorry I missed out website call! Opening up Trello boards now

Laura: don't worry - I've been working on the site generation in the mean time.

Hopefully you have seen from Trello - I have been busy on content!

I have the Trello for Android App. My phone was ringing a lot!

Bear - don't worry - we can robustify later. This is more to get something displaying content and the warm happy feeling that will motivate editors.

I'm not entirely sure how much time I have, FYI. Certainly a half hour. But we've guests upstairs here, and I'm assuming I'll be dragged out for a beer against my will later.

I'm happy to keep it as short as possible too.

Nothing big from my side other than we now have @xmpp for our use (finally)

Dave is really struggling with all the beer in his first week with us

there - now nothing on my agenda.

I also have nothing to talk about as I've been absent for a couple weeks

Laura, No, but the entire bottle of win in the hotel deal is a big of a strain.

A bottle of win.

let's bang the gavel and open for AOB?

he's kicking wifi and drinking "win" — sounds like an interesting hotel.

Se, struggling

Kev, I'll blame the crappy keyboard. Some fruit related product.

Grapes, if I understand what you mean by 'win'.

is ralphm present?

dwd, laura, simon - shall we start?

Go for it.

Lets

shall we make this the quickest meeting ever?

:)

Over already?

ok, dave, laura, simon and myself present - ralph abset

Simon - XMPP on twitter update?

other than "we have it and now can start using it"?

anyone else have any AOB items?

Yes, Tim (lead architect on Sina Weibo (which uses XMPP internally and is writing us a whitepaper)) has transferred the @xmpp username to us.

\o/

simon@imaginator.com: great!

nicely done sir on wrangling that!

Q: any good way to have a group of people using Twitter other than sharing a passwd?

that deserves some recognition

simon@imaginator.com: I am not aware of one, but that doesn't mean much

shared password or us signing up for one of the enterprisy web apps

I suggest it's tied to an xmpp.org email address, and the password shared to sensible people (like PSA, Laura).

I would also like to have it

We should limit the number of people sending the tweets too - mixed voices and messages confuse people

so that's my update. Website is keeping me busy but next week I should have more mental bandwidth to write up my XMPP "marketing team" proposal on how we can start getting more press.

but yes, +1 to xmpp.org address and the short list of folks

Nice idea is to hand over the reins to a fifferent person each week, and indetify that on our feed

Laura, Right, I'd prefer one person primary with the rest of the password holders for emergency cover.

Encourages people to hear each voice

Imagine 5 people all tweeting at once - different styles etc. Messy.

and that is why it's nice to have a marketing person in charge!

you betcha!

(in charge of "the message")

Happy to take that up

ugh - my brain is mush

I could try for a week, and get feedback from you guys on the content, style etc next week?

Laura: sounds awesome

See id you like it?

*if

no typos allowed in our tweets :-)

I promise to be very careful

stpeter: Rite, that would be a dizzaster.

Now hand it over

Laura - I'll ping you after with the details.

Great

:)

"Now hand it over" :-)

next item? AOB?

I sent out an invoice sample; heard back from Simon but nobody else.

I will reply to that on the lists

I think after some thought that the EIN might be required, but it otherwise looks good on a re-review.

But otherwise I've nothing more. (Little snowed under with new job etc)

dwd: I suppose the EIN isn't a bad idea

dwd: if you set the right juristriction in Wave - it makes sure to generate you a legal invoice.

stpeter: Yours had it, and some government agencies require it. May as well have it in for completeness.

BTW I mentioned our athena woes to my UPnP Forum contact and he offered for them to buy us a new machine

Ah, OK. I've not followed up with my potential at all; I can do that as well.

if we had a price estimate from the iteam I might be able to get something going quickly

My understanding from back around Christmas was that there were two machines that were getting quite tired.

Plus the iteam was, I thought, considering whether to maintain hardware or switch to a cloud provider.

Ralphm was also looking into getting a Rackspace box sponsored.

(could be easier than racking a new box)

we moved to Rackspace temporarily

having rackspace for the web content as backup is a great idea IMO

My preference would be to maintain the status quo. Jerry seemed a little put out that we'd moved athena away from him temporarily.

the iteam needs to decide whether to make that permanent

Yes, but we get quite incredible service from USSHC; we need to think hard about whether we want to end that relationship.

but some of what we run really should be run at the colo IMO

Kev: Jerry cares about jabber.org - I suggest we move that back to apollo or somesuch

and of course there's the question of xmpp.org and jabber.org, still :-)

FWIW, my gut feeling is to stick with Jerry. Invests in people instead of corporations, feels more satisfying. But I'll understand if the iteam want cloudish things as well (or even instead).

I'm not sure the iteam is pushing for a cloud at all.

it's still on my list to figure out a more independent funding source for jabber.org (cooperative or something), which would enable jabber.org to have separate machines for various purposes

It seems to be the discussions in the Board meetings that keep coming back to cloudifying.

Kev, That's fine, too. :-)

Kev - can we get an answer on price estimates from the iteam and then the cloud item will stop creeping into the conversation I think

Kev, I'm merely saying I'm not arguing the cloud option should be ruled out, not that I'm happy with it.

Could we have both hardware and price estimates. I may be able to get us a hardware sponsor, in which case the price is somewhat moot.

+1

I'm writing a mail at the moment.

thanks kev!

But I'm not a server hardware person.

I'm going to need to drop off in a minute. Anything else we need to go though after the hardware discussion?

no, but some of the iteam folk are - and if they give specs some of us can translate that to hardware price estimates

OK, I'm done with this.

dwd: +1 that would be helpful for the offer from UPnP Forum, too

(And no further AOB)

nothing further here

bear: Yes, that's why I sent said email.

meeting time same next week?

Great

love these 30-minute meetings

Do we have an EU timeshift this weekend?

bear: Noting that the 'same time next week' is in fact 17:30 instead of 16:30Z.

yes

If you're doing it UK-time, as Council does :)

yes, but since we use UTC the meeting time is the same

Assuming that Council has shifted, can we shift also?

bear: No, that's what I'm saying. You should shift the UTC time :)

That would be good for me, 5.30 could get trickier for longer meetings

I'd rather anchor to EU TZ shifting.

I always set up the calendar entries to be UTC, if we need to change then let me know

ah - the council time shifted

Or, at least, if your goal is to follow Council.

Council meets in UK time.

yes, following council is easier on a lot of folks

chronological imperialism!

Kev: Well, it follows EU timeshifting, at least. :-)

+1 to shifting out time - anyone object?

dwd: In the last discussion we had on the topic (and previous) Council agreed to meet at a given UK time :)

not hearing of any objections... ok, we shall shift our time also

Kev, so Council will move from 16:00 to 17:00 and Board will move from 16:30 to 17:30, right?

stpeter: Correct.

noted!

In Zulu time :)

So 5.30pm UK time?

Laura, No, it's unchanged in UK.

Laura - yes

Wait. No. I've screwed this up.

It's -1, not +1

(Or it should be)

So 15:00 and 15:30.

To counter the +1

yes

So it remains 16:00 and 16:30 UK.

How many XMPP experts does it take to schedule a meeting?

Kev: great

heehee

i've seen CalDAV experts mess up TZ calculations before...

thanks all - I think simon banged the gavel as he was leaving

ok!

Bye folks

something on one of my computers is beeping at me

bear: Is that because I keep saying your name in council@?

nope - it's silly facebook

I forgot that I had the tab running and everytime it updates the timeline it beeps

emcho, there?