> > >>>>> All ThreadsML threads should understand the same
> > vocabulary. If
> > we start referencing lists of references or verbs = Oi.
>
> I agree with the weasel ;-)
> To get at an existing thread, all that should be needed is
> (RESTful) http gets. I'm not sure that the ability *to
> create* and add a currently non-existent post to a thread is
> necessary or desirable. Post creation is completely
> open-ended (blogger, email, QT...), so I reckon the creation
> of the posts should be left to the other systems, and for
> ThreadsML, pointers to the
> (readable) leaves of the thread should be enough.
>

I agree with Danny. ThreadML is going to be complex enough without trying to encompass the multiple ways in which applications might accept new threads. Not to mention all the new ways we haven't thought of yet!
Cheers,

Matt

I agree as well that it's better to keep it simple. But you knew that :-)

The issue of API discoverability is covered by other specs, as is authentication (something we haven't talked about much before in relation to APIs). I think they're separable from ThreadsML.

So maybe the imagined central app that lets me view all my 'feeds' needs app-specific API handling internally. I think that's a reasonable compromise that doesn't negate it as a valid use case.

OK - the marketing dept is gonna speak up again (this is of course without permission from other members of the marketing dept - but we're all just ants here anyway, so..............)

Obviously ThreadsML can't do everything itself.

The particular point that got us all going today is how many APIs get piled INTO the spec - versus a reference table - to point at a
particular set of APIs for each app.

I hate to play devil's advocate, but when I read what Danny said:
I'm not sure that the ability *to create* and add a currently
non-existent post to a thread is necessary or desirable. Post creation is completely open-ended (blogger, email, QT...), so I reckon the creation of the posts should be left to the other systems, and for ThreadsML, pointers to the
(readable) leaves of the thread should be enough.

I get nervous.

OF COURSE we want to be able to create new posts to a thread! I go to an existing conversation, I wanna add my 2 cents, I GOTTA be able to do that!

Now the issues are (I think):
 - which app do I use to do that with - well my business guy hat
on says "if the app is smart enough or supports the right features, than you can."
 - does that mean that the ThreadsML data carries around
something that enables an app to add a thread. I'd say no. It's the ThreadsML APIs - which are SUPPORTED by these new kind of apps - which enable adding new posts (again - maybe I'm just dumb - but there's nothing wrong asking dumb questions..........)
 - but what does that have to do with the ThreadsML data itself?
 - something in there HAS to be able to support a multi-vendor
universe - where all sorts of apps, tools, systems, etc. - can
contribute EQUALLY
 - can create ThreadsML complaint threads - EQUALLY - with no
implied prejudice or one-upmanship - because it was created in a message board or mail list, as opposed to an IM client or digital lifestyle aggregator.

Does that seem right?

< replied-to message removed by QT >

Hi folks,

I admit I've been pretty busy so I've had to skim a bit here and there. Maybe I missed something important?

It seemed to me that the idea of ThreadsML was to create an ML, i.e. a mark-up language. A way of representing threaded communications that would permit interchange between all kinds of applications. Did I miss the announcement of that because I'm seeing a lot of conversation about API's now. I'd prefer to get the ThreadsML data right and worry about how to cart it around the internet later.

Once people have actually tried doing it for real, then we will begin to see what sort of shapes the API's will have to take. Anything else is putting the cart before the horse.

Maybe I'm off base, if so just tell me to shut up.

Regards,

Matt

I think having a ThreadsML data structure is important too - maybe it's just RSS - with some fancy something or other - but it's gotta be something that can be backed up, archived, searched, moved around - and we can't do that to lots of different things.

ThreadsML threads have to be in a ThreadsML format.

Correct?

That then goes along with a bunch of ThreadsML APIs - which (eventually) can get stored in a persistent repository and be discoverable.

Correct?

< replied-to message removed by QT >

Matt Mower wrote (among other things):
> It seemed to me that the idea of ThreadsML was to create an ML,
> i.e. a mark-up language.

From my perspective, this still holds, true, but I think we're seeing that many of the use cases beyond the original 2 use cases ("import/export" and "reading a multi-hosted thread through a single app or site") involve inter-app communication. I definitely agree that there's a lot of value in just nailing the markup language, and as far as I'm concerned there's nothing impeding us from doing that right now.

But I also think it's worthwhile discussing APIs, etc., especially because they're wrapped up with other interesting use cases.

So far I see several possible phases of spec and conformance.

With the ThreadsML data standard, apps can support:
1. Export-only
2. Export and Import, but not round-trip (i.e. import, export, re-import of the same thread)
3. Export/Import with round-trip.

[There's also import-only, with the attitude "I'll take your threads, but you can't take 'em back", but what user wants that?]

Even with just the data standard, and some RSS-like ways of getting ThreadsML content either through regular publication to fixed URIs, or dynamic updating to fixed URIs, people can write very interesting apps that could allow posting to threads from a single interface, but they'd need to write to each supported app's XML-RPC, SOAP, HTTP POST, or whatever API.
Beyond that, we can work towards a common API. But again I don't see any need to prevent conversation about that now.

Note to self: learn about REST:
http://webservices.xml.com/pub/a/ws/2002/02/20/rest.html
http://internet.conveyor.com/RESTwiki/moin.cgi

http://dannyayers.com/2003/05/19/qt-19-52.htm

< replied-to message removed by QT >

It's a bit carping/politically motivated, but Tim Bray posted a very handy little REST synopsis a few days ago:

http://tbray.org/ongoing/When/200x/2003/05/12/SoapAgain

little follow-up

http://tbray.org/ongoing/When/200x/2003/05/14/Technorati2




< replied-to message removed by QT >

I just wanna know one thing - how come this post:
(http://dannyayers.com/2003/05/19/qt-19-52.htm) is on a separate
webpage?

Do I hear "content aggregator" coming down the pike? Some new kind of cool new what-sa-ma-callit?

What's up with this?

< replied-to message removed by QT >

Steve wrote.....

....but they'd need to write to each supported app's XML-RPC, SOAP, HTTP POST, or whatever API..

Marc replies....

I don't see anything wrong with that. A role of a ThreadsML alliance (notice a trend here?) might be to coordinate all those APIs - so everyone else can find them in one place - and support them accordingly.
< replied-to message removed by QT >

Marc wrote:
> coordinate all those APIs - so everyone else can find them in one place - and support them accordingly.

I like that idea! How about doing that on the http://www.threadsml.org page right now?

Hi guys,

Okay. I'm not looking to prevent conversation about a ThreadsML API. I guess I'm just not interested in the API at this point, where I am interested in what the data will look like. When I hear talk of the API I just have visions of the ocean bubbling away.

BTW: Has anyone read Paolo's idea[1] for adding source GUID's to RSS feeds as an extension?

Regards,

Matt

[1] http://blogs.law.harvard.edu/crimson1/2003/05/17#a282

OK - cool

What products support it now and what are their APIs?

:-)

< replied-to message removed by QT >

> I just wanna know one thing - how come this post:
> (http://dannyayers.com/2003/05/19/qt-19-52.htm) is on a separate
> webpage?

Seemed a quick way of making the point...

> Do I hear "content aggregator" coming down the pike? Some new
> kind of cool new what-sa-ma-callit?

Nope, not this time.
But how would ThreadsML deal with every new kind of cool new
what-sa-ma-callit?

Good point

There should be some low- hanging fruit - easy to grok - "built-in" functions - which all apps should/would support.

I know that seems to contradict what we were just saying, but not that big of a deal. Is it?

< replied-to message removed by QT >