While the car/bus thing is fun, imho it doesn't apply here.
I think the blogger community needs a broad-coverage api that encourages
other content systems to adopt the blogging gesture. I think those working
on the 'back-end' of the blogosphere (servers, editors, aggregators) should
be working to make the api as friendly as possible for all content storage
systems.
For this reason, I think the group needs to focus on an api set that is
product-brand agnostic. We need to include the well-known entry-points, of
course (no need to re-invent the wheel). But we also need to think a bit
outside the box in terms of how interactions with various back-ends work.
Finally, (and I say this with some trepidation) I've seen this community get
close to a cross-product standard a few times only to stop cold when folks
start to think they're getting their feelings hurt or getting 'shafted' by
some other person or product or brand. We gotta cut that out. Creating a
community standard is not a threat to any one product and it's not a boon to
any one product, either. Also, accepting/rejecting an api or portion
thereof is neither an indictment or sanctifying of any one person or
product.
Now rcade has made an excellent effort to get us all on the same card.
Let's not squander the gift he's attempting to give us. Let's commit to
sticking with this to the end (end being a community-wide api for supporting
blogging).
This list (and others) has the kind of minds and talent to build a fantastic
blogging system for everyone to use. Let's just do it, eh?
MCA
> -----Original Message-----
> From: Dave Winer [mailto:dave@...]
> Sent: Saturday, May 10, 2003 1:53 PM
> To: MetaWeblog-API@yahoogroups.com
> Subject: Re: [MetaWeblog-API] Re: Extending the API
>
> Well, I gave this some thought -- and I'm sorry to disappoint, but I don't
> love the idea. :-(
>
> Let me explain with an analogy. Suppose I had a bus. I drove around in the
> bus all the time, and life was good.
>
> Then I got a car. When it was just me driving around I'd take the car.
> Easier to handle, better mileage, etc.
>
> Then one day Detroit came out with an idea. Let's include a bus with every
> car! Then people could do all the things with their car that they do with
> a bus. It would cost more, and take a lot longer to learn how to drive.
> But why not, after all it would be very useful.
>
> Where does it stop? It would be nice to have an airplane in there too. But
> why not use a car when you want to drive by car, and a bus when you want a
> bus, and an airplane when you want one of those?
>
> Let's keep the xmlStorageSystem and MetaWeblog APIs as separate things. If
> you want to implement both, that would be excellent. If you only need one,
> that's cool too.
>
> Dave
>
>
> ----- Original Message -----
> From: rcade
> To: MetaWeblog-API@yahoogroups.com
> Sent: Thursday, May 08, 2003 1:09 PM
> Subject: [MetaWeblog-API] Re: Extending the API
>
>
> --- In MetaWeblog-API@yahoogroups.com, "journurl" <rogben@s...> wrote:
> > I dunno. Maybe Dave will love the idea, but it sounds like trouble
> > to me.
>
> I suspect that he might, since it's already available on UserLand,
> Salon Blogs, and PyCS community servers.
>
> Sites that don't want to support user registration through the API can
> indicate this in the return of
> metaWeblog.getServerCapabilities(username, password). The returned
> struct includes allowNewMembers, which if false indicates the host
> isn't allowing new registrations.
>
> It could be stated into the API spec that if a server returns false in
> allowNewMembers, the metaWeblog.registerUser and
> metaWeblog.deregisterUser will always return false.
>
>
> Yahoo! Groups Sponsor
>
>
>
>
>
> To unsubscribe from this group, send an email to:
> MetaWeblog-API-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
>
>
> [Non-text portions of this message have been removed]
>
>
>
> To unsubscribe from this group, send an email to:
> MetaWeblog-API-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
Well, I gave this some thought -- and I'm sorry to disappoint, but I don't love
the idea. :-(
Let me explain with an analogy. Suppose I had a bus. I drove around in the bus
all the time, and life was good.
Then I got a car. When it was just me driving around I'd take the car. Easier to
handle, better mileage, etc.
Then one day Detroit came out with an idea. Let's include a bus with every car!
Then people could do all the things with their car that they do with a bus. It
would cost more, and take a lot longer to learn how to drive. But why not, after
all it would be very useful.
Where does it stop? It would be nice to have an airplane in there too. But why
not use a car when you want to drive by car, and a bus when you want a bus, and
an airplane when you want one of those?
Let's keep the xmlStorageSystem and MetaWeblog APIs as separate things. If you
want to implement both, that would be excellent. If you only need one, that's
cool too.
Dave
----- Original Message -----
From: rcade
To: MetaWeblog-API@yahoogroups.com
Sent: Thursday, May 08, 2003 1:09 PM
Subject: [MetaWeblog-API] Re: Extending the API
--- In MetaWeblog-API@yahoogroups.com, "journurl" <rogben@s...> wrote:
> I dunno. Maybe Dave will love the idea, but it sounds like trouble
> to me.
I suspect that he might, since it's already available on UserLand,
Salon Blogs, and PyCS community servers.
Sites that don't want to support user registration through the API can
indicate this in the return of
metaWeblog.getServerCapabilities(username, password). The returned
struct includes allowNewMembers, which if false indicates the host
isn't allowing new registrations.
It could be stated into the API spec that if a server returns false in
allowNewMembers, the metaWeblog.registerUser and
metaWeblog.deregisterUser will always return false.
Yahoo! Groups Sponsor
To unsubscribe from this group, send an email to:
MetaWeblog-API-unsubscribe@yahoogroups.com
Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
[Non-text portions of this message have been removed]
--- journurl <rogben@...> wrote:
> Why would you be telling your users anything of the sort? If you've
> got a client tool that handles signups and content creation, and an
Ah, but I'm not the one building that tool. I prefer to leave that to
someone else. I'm more interested in what messages that tool might
send my way, and there a single API is of more value.
> > Creating an account in tangential?
>
> Yup. IMO, it has nothing to do with manipulating blog entries. Users
> and the content they create are distinct things that need their own
I think we'll have to agree to disagree. I believe the user is the
content (or the content is the user?).
Lance
__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com
--- In MetaWeblog-API@yahoogroups.com, Lavandowska
<flanandowska@y...> wrote:
> What if they aren't using Radio et al? I'd like to support this
> functionality all under one API rather than two: I don't want to
tell
> my users "Use this API/tool for posting and stuff, use that other
one
> for creating your account."
Why would you be telling your users anything of the sort? If you've
got a client tool that handles signups and content creation, and an
RSD file that tells that tool what APIs you support, then there's
really no problem for the user. There could be ten unique APIs
operating beneath the surface and they'd never know.
> Creating an account in tangential?
Yup. IMO, it has nothing to do with manipulating blog entries. Users
and the content they create are distinct things that need their own
APIs.
--
Roger
http://admin.support.journurl.com/
--- journurl <rogben@...> wrote:
> > API-based signup is already supported on Radio.Weblogs.Com, Salon
> > Blogs, Pycs.Net, and other hosts running a community server.
>
> So why integrate a functional, pre-existing API into metaWeblog? If
> developers want to support that sort of functionality, why wouldn't
> they just use xmlStorageSystem?
What if they aren't using Radio et al? I'd like to support this
functionality all under one API rather than two: I don't want to tell
my users "Use this API/tool for posting and stuff, use that other one
for creating your account."
> particularly compelling reason to clutter up a sleek little blog-
> entry API with methods that are --at best-- tangential to the
> purposes of processing blog entries.
Creating an account in tangential?
Granted, the xMultipleFiles() methods presuppose a file-based system.
But I'm free to ignore them if I choose.
Lance Lavandowska
http://www.brainopolis.com/roller/page/lancehttp://www.rollerweblogger.org
__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com
--- In MetaWeblog-API@yahoogroups.com, "journurl" <rogben@s...> wrote:
> I dunno. Maybe Dave will love the idea, but it sounds like trouble
> to me.
I suspect that he might, since it's already available on UserLand,
Salon Blogs, and PyCS community servers.
Sites that don't want to support user registration through the API can
indicate this in the return of
metaWeblog.getServerCapabilities(username, password). The returned
struct includes allowNewMembers, which if false indicates the host
isn't allowing new registrations.
It could be stated into the API spec that if a server returns false in
allowNewMembers, the metaWeblog.registerUser and
metaWeblog.deregisterUser will always return false.
> I've already replied to this once, but it must
> have been eaten by a grue.
That's what you get for letting your torch burn out. :)
> API-based signup is already supported on Radio.Weblogs.Com, Salon
> Blogs, Pycs.Net, and other hosts running a community server.
So why integrate a functional, pre-existing API into metaWeblog? If
developers want to support that sort of functionality, why wouldn't
they just use xmlStorageSystem?
> Implementors who don't want to offer API signup can
> implement this easily:
Perhaps, but the slip side of that coin is that, as you've pointed
out, those who *do* want it can already get it. I don't see a
particularly compelling reason to clutter up a sleek little blog-
entry API with methods that are --at best-- tangential to the
purposes of processing blog entries.
--
Roger Benningfield
I've already replied to this once, but it must have been eaten by a
grue.
--- In MetaWeblog-API@yahoogroups.com, "journurl" <rogben@s...> wrote:
> Things like user creation are just too big to leave to a general
> API. After all, user creation is a process with a user interface,
> not a function call.
API-based signup is already supported on Radio.Weblogs.Com, Salon
Blogs, Pycs.Net, and other hosts running a community server. While I
can understand that some hosts wouldn't want this feature, it would be
useful to have it in the MetaWeblog API for those that do.
One thing in its favor is how easy it is to implement if you don't
want to allow signups.
One of the values returned by metaWeblog.getServerCapabilities() is
allowNewMembers, a boolean indicating whether new members can be
registered (true) or not (false).
Implementors who don't want to offer API signup can implement this
easily: return false in allowNewMembers and implement empty
metaWeblog.registerUser() and metaWeblog.deregisterUser() methods that
always return false.
It's going to take some time to digest this, but I'm sure you already knew that.
It would be easier to point to, btw, if it were on the Web. Yahoo tends to
mangle docs like this. Dave
----- Original Message -----
From: rcade
To: MetaWeblog-API@yahoogroups.com
Sent: Thursday, May 08, 2003 12:07 PM
Subject: [MetaWeblog-API] Extending the API
A repost from my weblog:
Dave Winer is proposing a new version of the MetaWeblog API, an
XML-RPC interface for weblog publishing that's supported by
Archipelago, Blojsom, Radio Userland, Manila, Moveable Type,
NetNewsWire, Python Desktop Server, and Zoe.
In addition to incorporating some omitted methods from the Blogger
API, I'd like to suggest that the MetaWeblog API implement some of the
features of XmlStorageSystem, the XML-RPC API used to publish a weblog
on a community server such as the Radio Community Server or Python
Community Server.
The goal would be a completely tool-agnostic weblog protocol that can
be used to create and publish a weblog without ever using any other
software. It could take Really Simple Discoverability even further --
a new user would only need to select a username and password before
creating a weblog. Everything else could be handled by a tool through
the API.
I've tried to limit this to features that are already implemented in
one of the aforementioned APIs (with one exception at the end).
My suggestions:
1. Implement the undocumented methods offered in the Blogger API,
which Mike Amundsen has documented, and the new MetaWeblog API methods
in current use.
metaWeblog.getRecentPosts(blogid, username, password, numberOfPosts)
returns struct
The return value is a string array of postid values. Blogger only
returned up to 20 posts in this manner, but it would be nice for
backup purposes if 0 could be specified as the numberOfPosts argument
to receive the entire weblog.
metaWeblog.deletePost(postid, username, password) returns boolean
The return value indicates success (true) or failure (false).
metaWeblog.newMediaObject(blogid, username, password, struct) returns
struct
The struct must contain at least three elements, name, type and bits.
name is a string, it may be used to determine the name of the file
that stores the object, or to display it in a list of objects. It
determines how the weblog refers to the object. If the name is the
same as an existing object stored in the weblog, it may replace the
existing object.
type is a string, it indicates the type of the object, it's a standard
MIME type, like audio/mpeg or image/jpeg or video/quicktime.
bits is a base64-encoded binary value containing the content of the
object.
The struct may contain other elements, which may or may not be stored
by the content management system.
If newMediaObject fails, it throws an error. If it succeeds, it
returns a struct, which must contain at least one element, url, which
is the url through which the object can be accessed. It must be either
an FTP or HTTP url.
metaWeblog.getCategories (blogid, username, password) returns struct
The struct returned contains one struct for each category, containing
the following elements: description, htmlUrl and rssUrl.
This call allows editing tools to offer category-routing as a feature.
2. Implement some methods based on features of XmlStorageSystem.
metaWeblog.registerUser(username, password, email, useragent,
contactinfo) returns string
The return value is the blogid of the new weblog (if successful) or
"false" otherwise. The useragent argument is optional; it identifies
the software used. The contactinfo argument is a struct containing
optional contact information for the user (as strings): name,
streetaddress1, streetaddress2, city, state, zip, phone, fax,
alternateemail.
metaWeblog.getServerCapabilities(username, password) returns struct
The struct returned by the method contains:
legalFileExtensions, a array of file extensions that may be uploaded
to the weblog
maxFileSize, a number, the maximum file size
maxBytesPerUser, a number, the maximum number of bytes allowed per
user
ctBytesInUse, the number of bytes in use by the indicated user
upstreamFolderUrl, a string, the URL of the folder containing the
files
allowNewMembers, a boolean, indicating whether new members currently
can be registered (true) or not (false)
The struct also can contain additional optional elements such as the
URL of a comment server and other implementation-specific features.
metaWeblog.mailPasswordToUser(username) returns true
Sends the password associated with that username to the e-mail address
associated with the account. Always returns true, whether or not the
username is valid.
metaWeblog.saveMultipleFiles(username, password, relativepathList,
fileTextList) returns struct
A method to publish one or more files to the same location as the
weblog (or its subfolders).
relativePathList is a array of strings, each of which identifies the
location of the corresponding file in the fileTextList, relative to
the top level of the user's HTTP-accessible directory. The path is
slash-separated, and may or may not start with a slash. Example:
sounds/clock.mp3.
fileTextList is an array of strings, containing the text to be stored
in a file.
saveMultipleFiles returns a struct containing urlList, a array of HTTP
urls corresponding to the files that were saved. If there was an error
saving the file its url in urlList is the empty string.
If there was an error preventing files from being saved, the struct
contains flError, which indicates there was an error, and message,
which provides human readable text explaining the error.
metaWeblog.deleteMultipleFiles(username, password, relativepathList,
fileTextList) returns struct
Like saveMultipleFiles, except that it deletes files instead of saving
them.
3. Implement one additional method.
metaWeblog.deregisterUser(username, password, email) returns boolean
A method to remove a weblog entirely from publication -- implementors
can choose whether this deletes the site or simply makes it
inaccessible. The return value is true if successful or false
otherwise.
Yahoo! Groups Sponsor
To unsubscribe from this group, send an email to:
MetaWeblog-API-unsubscribe@yahoogroups.com
Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
[Non-text portions of this message have been removed]
--- In MetaWeblog-API@yahoogroups.com, "rcade" <rogers@c...> wrote:
> In addition to incorporating some omitted methods from the Blogger
> API, I'd like to suggest that the MetaWeblog API implement some of
the
> features of XmlStorageSystem...
I hate to be disagreeable, but... yikes! IMO, most of that stuff is
far better suited to app-specific APIs, or at least some sort of
optional API extension (metaWeblogEX?) that tool providers will know
in advance may be unsupported.
Things like user creation are just too big to leave to a general
API. After all, user creation is a process with a user interface,
not a function call. For example, if you're running a hosted
service, people are usually expected to agree to a TOS document of
some kind before they can create an account. Implementing that sort
of thing via the API would be clunky at best.
It just gets worse from there. My app needs a username during
signup, supplies a randomly generated password via email for
validation, and then requires the user to create a "public" ID on a
per-community basis. That would be a serious pain for client authors
to accomodate.
I dunno. Maybe Dave will love the idea, but it sounds like trouble
to me.
--
Roger Benningfield
http://admin.support.journurl.com/
A repost from my weblog:
Dave Winer is proposing a new version of the MetaWeblog API, an
XML-RPC interface for weblog publishing that's supported by
Archipelago, Blojsom, Radio Userland, Manila, Moveable Type,
NetNewsWire, Python Desktop Server, and Zoe.
In addition to incorporating some omitted methods from the Blogger
API, I'd like to suggest that the MetaWeblog API implement some of the
features of XmlStorageSystem, the XML-RPC API used to publish a weblog
on a community server such as the Radio Community Server or Python
Community Server.
The goal would be a completely tool-agnostic weblog protocol that can
be used to create and publish a weblog without ever using any other
software. It could take Really Simple Discoverability even further --
a new user would only need to select a username and password before
creating a weblog. Everything else could be handled by a tool through
the API.
I've tried to limit this to features that are already implemented in
one of the aforementioned APIs (with one exception at the end).
My suggestions:
1. Implement the undocumented methods offered in the Blogger API,
which Mike Amundsen has documented, and the new MetaWeblog API methods
in current use.
metaWeblog.getRecentPosts(blogid, username, password, numberOfPosts)
returns struct
The return value is a string array of postid values. Blogger only
returned up to 20 posts in this manner, but it would be nice for
backup purposes if 0 could be specified as the numberOfPosts argument
to receive the entire weblog.
metaWeblog.deletePost(postid, username, password) returns boolean
The return value indicates success (true) or failure (false).
metaWeblog.newMediaObject(blogid, username, password, struct) returns
struct
The struct must contain at least three elements, name, type and bits.
name is a string, it may be used to determine the name of the file
that stores the object, or to display it in a list of objects. It
determines how the weblog refers to the object. If the name is the
same as an existing object stored in the weblog, it may replace the
existing object.
type is a string, it indicates the type of the object, it's a standard
MIME type, like audio/mpeg or image/jpeg or video/quicktime.
bits is a base64-encoded binary value containing the content of the
object.
The struct may contain other elements, which may or may not be stored
by the content management system.
If newMediaObject fails, it throws an error. If it succeeds, it
returns a struct, which must contain at least one element, url, which
is the url through which the object can be accessed. It must be either
an FTP or HTTP url.
metaWeblog.getCategories (blogid, username, password) returns struct
The struct returned contains one struct for each category, containing
the following elements: description, htmlUrl and rssUrl.
This call allows editing tools to offer category-routing as a feature.
2. Implement some methods based on features of XmlStorageSystem.
metaWeblog.registerUser(username, password, email, useragent,
contactinfo) returns string
The return value is the blogid of the new weblog (if successful) or
"false" otherwise. The useragent argument is optional; it identifies
the software used. The contactinfo argument is a struct containing
optional contact information for the user (as strings): name,
streetaddress1, streetaddress2, city, state, zip, phone, fax,
alternateemail.
metaWeblog.getServerCapabilities(username, password) returns struct
The struct returned by the method contains:
legalFileExtensions, a array of file extensions that may be uploaded
to the weblog
maxFileSize, a number, the maximum file size
maxBytesPerUser, a number, the maximum number of bytes allowed per
user
ctBytesInUse, the number of bytes in use by the indicated user
upstreamFolderUrl, a string, the URL of the folder containing the
files
allowNewMembers, a boolean, indicating whether new members currently
can be registered (true) or not (false)
The struct also can contain additional optional elements such as the
URL of a comment server and other implementation-specific features.
metaWeblog.mailPasswordToUser(username) returns true
Sends the password associated with that username to the e-mail address
associated with the account. Always returns true, whether or not the
username is valid.
metaWeblog.saveMultipleFiles(username, password, relativepathList,
fileTextList) returns struct
A method to publish one or more files to the same location as the
weblog (or its subfolders).
relativePathList is a array of strings, each of which identifies the
location of the corresponding file in the fileTextList, relative to
the top level of the user's HTTP-accessible directory. The path is
slash-separated, and may or may not start with a slash. Example:
sounds/clock.mp3.
fileTextList is an array of strings, containing the text to be stored
in a file.
saveMultipleFiles returns a struct containing urlList, a array of HTTP
urls corresponding to the files that were saved. If there was an error
saving the file its url in urlList is the empty string.
If there was an error preventing files from being saved, the struct
contains flError, which indicates there was an error, and message,
which provides human readable text explaining the error.
metaWeblog.deleteMultipleFiles(username, password, relativepathList,
fileTextList) returns struct
Like saveMultipleFiles, except that it deletes files instead of saving
them.
3. Implement one additional method.
metaWeblog.deregisterUser(username, password, email) returns boolean
A method to remove a weblog entirely from publication -- implementors
can choose whether this deletes the site or simply makes it
inaccessible. The return value is true if successful or false
otherwise.
I think it's totally nuts that they express compatibility in terms of products,
not APIs. I hope someone competes with them and zigs to their zag. Dave
----- Original Message -----
From: journurl
To: MetaWeblog-API@yahoogroups.com
Sent: Monday, April 28, 2003 5:06 PM
Subject: [MetaWeblog-API] audblog
Dave: I note that the audblog folks are now supporting Movable
Type... any word on how long it'll be before we see metaWeblog API
support? Or is that just not going to happen?
--
Roger
JournURL
http://journurl.com/
my blog
http://admin.support.journurl.com/
Yahoo! Groups Sponsor
To unsubscribe from this group, send an email to:
MetaWeblog-API-unsubscribe@yahoogroups.com
Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
[Non-text portions of this message have been removed]
Dave: I note that the audblog folks are now supporting Movable
Type... any word on how long it'll be before we see metaWeblog API
support? Or is that just not going to happen?
--
Roger
JournURL
http://journurl.com/
my blog
http://admin.support.journurl.com/
We are recruiting professionals in the following areas,
Tech Lead: 2 positions
Experinece : 5 - 8
Required Skills:
Strong leader, should have managed people, very good ("effective")
communicator, should be able talk and direct team members & clients
remotely.
Proactive and "Get it Done" attitude, ready travel anytime.
Software design techniques - UML, object-oriented analysis and design
techniques
Experience overall software development experience
Strong experience in Visual C++, ATL, MFC and COM - is a must
Experience in Visual Basic (VB6) and COM - (must know VB)
Strong White box unit tester understand the concept of white box
testing of APIs
Experience in CPPUnit/JUnit/ VBUnit ....
Concepts in Java (for developing test case in Java side)
Oracle /SQL experience - (for developing test case in Java side)
If you are interested, forward latest version of your resume else
could suggest a few refferals.
Job Location : Hyderabad
Best Regards
Can someone clarify something for me?
The spec says that metaWeblog.getCategories returns a struct. Is it
suppose to be an array of structs? Or is it really a struct of structs,
and the spec isn't being clear about what the members of the parent
struct are?
Can someone post a sample response?
Also, Dave -- is metaWeblog.getRecentPosts official or not? And if so,
how about adding it to the spec? And if not, how about adding it to the
spec? :)
--
Ernest MacDougal Campbell III, MCP+I, MCSE <dougal@...>
http://dougal.gunters.org/http://spam.gunters.org/
Web Design & Development: http://www.mentalcollective.com/
This message is guaranteed to be 100% eror frea!
Jon Davis [mailto:jon@...] wrote:
> The specification does not describe "category". Is this an ID
> of a category? Is it possible to simply submit the full
> string of a category name along with a post to Radio and
> expect to see the post in the appropriate category?
You're right it doesn't. It actually leaves it open to interpretation. In
the implementations I've seen (Radio and Blogger) however, it is the string
name of the category.
HTH,
Drew
[ .NET MVP | weblog: http://dotnetweblogs.com/dmarsh ]
Although it's not doc'ed I found that there are two 'modes' of category
support for metaWeblog API:
Single category (SC)
Multi category (MC)
In SC, you simply supply <category>Main Ctegory</category> as part of the
post struct.
In MC, you supply the array of categories as described in the RFC on Daves
site.
MCA
> -----Original Message-----
> From: Jon Davis [mailto:jon@...]
> Sent: Friday, March 07, 2003 12:51 PM
> To: MetaWeblog-API@yahoogroups.com
> Subject: [MetaWeblog-API] Category field
>
> The specification does not describe "category". Is this an ID of a
> category?
> Is it possible to simply submit the full string of a category name along
> with a post to Radio and expect to see the post in the appropriate
> category?
>
> Thanks,
> Jon
>
>
> [Non-text portions of this message have been removed]
>
>
>
> To unsubscribe from this group, send an email to:
> MetaWeblog-API-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
The specification does not describe "category". Is this an ID of a category?
Is it possible to simply submit the full string of a category name along
with a post to Radio and expect to see the post in the appropriate category?
Thanks,
Jon
[Non-text portions of this message have been removed]
Radio and Manila both support the MetaWeblog API.
----- Original Message -----
From: "rick" <rick@...>
To: <MetaWeblog-API@yahoogroups.com>
Sent: Wednesday, February 26, 2003 4:07 AM
Subject: Re: [MetaWeblog-API] Which service already uses MetaWeblog-API?
> I believe that Movable Type supports the MetaWeblog API. I doubt
> Blogger will ever support the MetaWeblog API. Ev always made it seem
> it'd be the Blogger API or nothing...
>
> MT Manual on XML-RPC interfaces --
> http://www.movabletype.org/docs/mtmanual_programmatic.html
>
> rick
> http://techno-weenie.com
>
> dennisluemkemann wrote:
>
> >I'm developing a blog-tool and would like to be able to upload
> >pictures with posts. The MetaWeblog API seems to be the right (and
> >only?) thing. But which (free) blog services support that api?
> >Does anybody know when/if blogger.com will support it?
> >
> >Thanks
> >Dennis
> >
> >
> >
> >
> >To unsubscribe from this group, send an email to:
> >MetaWeblog-API-unsubscribe@yahoogroups.com
> >
> >
> >
> >Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
> >
> >
> >
> >
> >
> >
>
>
>
>
>
> To unsubscribe from this group, send an email to:
> MetaWeblog-API-unsubscribe@yahoogroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
Hola:
El Wednesday 26 February 2003 11:46, dennisluemkemann
<dennis.luemkemann@...> tecleó:
> I'm developing a blog-tool and would like to be able to upload
> pictures with posts. The MetaWeblog API seems to be the right (and
> only?) thing. But which (free) blog services support that api?
> Does anybody know when/if blogger.com will support it?
For my blog server (Blogalia), I also miss functions for
posting/deleting comments. The Blogger API 2.0 spec is here
http://groups.yahoo.com/group/bloggerDev/files/documentation.html and it
doesnt support either file or comment posts.
Greetings,
--
Víctor R. Ruiz | - Todos estos momentos se perderán, como
http://infoastro.com/rvr | lágrimas en la lluvia.
I believe that Movable Type supports the MetaWeblog API. I doubt
Blogger will ever support the MetaWeblog API. Ev always made it seem
it'd be the Blogger API or nothing...
MT Manual on XML-RPC interfaces --
http://www.movabletype.org/docs/mtmanual_programmatic.html
rick
http://techno-weenie.com
dennisluemkemann wrote:
>I'm developing a blog-tool and would like to be able to upload
>pictures with posts. The MetaWeblog API seems to be the right (and
>only?) thing. But which (free) blog services support that api?
>Does anybody know when/if blogger.com will support it?
>
>Thanks
>Dennis
>
>
>
>
>To unsubscribe from this group, send an email to:
>MetaWeblog-API-unsubscribe@yahoogroups.com
>
>
>
>Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>
>
>
>
I'm developing a blog-tool and would like to be able to upload
pictures with posts. The MetaWeblog API seems to be the right (and
only?) thing. But which (free) blog services support that api?
Does anybody know when/if blogger.com will support it?
Thanks
Dennis
Welcome to the MetaWeblog-API mail list.
This list is open to all developers who are implementing the MetaWeblog API,
and people who wish to participate in the discussion of the evolution of the
protocol.
Please keep the discussion professional at all times. If the list flames out
as they sometimes do, I will temporarily turn on moderation to get the list
back on track. So there's really no point getting personal.
Later today we'll freeze a new entry-point to kick things off.
Let's have fun!
Dave