Log in

No account? Create an account
Previous Entry Share Next Entry
(no subject)
тайные знания
quirrc wrote in ljwin32_sema

What API should Semagic support?

I already use another (better) client for non-LJ-specific API

(the aim is to allow people to work with other sites from the same client, not to work with LJ using another protocol because all other protocols besides LJ-specific one lack features)
Next release of the client will support Atom.

Application Program(ming) Interface.

I've heard of Atom as a API,
but not MetaWeblog.

Can you post links.

why do you need to support more apis?

Isn't the lj interface compatible with blogger?

You need another button for "Whatever works, 'cause I don't know what you are talking about!"

That was the sound of your questions whizzing, unchecked, over my head. :-)

same here.

random question, you look friendly enough, so i figured i'd ask- what is up with those icons? i feel like i'm missing something major here...


Well from reading about Atom I have to say that it seems very powerful and benificial. My vote is for Atom all the way.

What about, I don't care, I wouldn't use it anyway?

Same here. I use Semagic with LiveJournal and one or two LiveJournal clones, and it works fine; I don't have the need for it to work with any site running anything else.

I have no clue about any of this API jargon. But i'm assuming it's for the people that create the clients. I don't know if it actually benifits the users of such programs, but whatever works and whatever is easier for the dude.

So I guess i'll just vote Atom anyways just because it's in the lead.

WEll so much for voting. Don't see any option anywhere to actually cast a vote. meh. my word is enough I suppose.

I think in the past most of us have voted to keep Semagic simple and on-task. The notion that if a program is good at one thing it it should be bloated with other features to make it the swiss-army knife of clients is, in my opinion, ridiculous. Long before I would do that, I'd focus on cleaning up the interface, applying user's styles to the previews, including mood icons in the interface, etc. Focus on making Semagic the best LJ client it can be.

Mood icons are not avialable to clients, user style in preview is achieved using custom preview template. Basic atom support whould be visible externally as a little combobox in the server settings with api type and less than 1% of the source code.

I'm glad you asked this; I voted for Atom. I think that's definitely the one to support, for several reasons. While the Atom API had problems in past years with the working group reaching a consensus on various things, real progress has been made.

For those less familiar with all this, just like Semagic is a LiveJournal client, there are clients for other journal/blog sites too. Talking about APIs (Application Programming Interface) is about discussing tools and protocols that allow people to use an editor without having to use a textbox on a webpage (just like Semagic allows). LiveJournal has its own API called XML-RPC. Theirs is special [:-)] because it has things like Friends groups support, moods, music & the like (specific to LiveJournal based sites). That's all cool - they had to write their own so that programs (like the great Semagic) could connect and post to use these LJ features. Plus, at the time, there was pretty much no Atom (formerly Echo), no MetaWeblog yet either I believe.

The difference with APIs like Atom is that they offer a standard interface to implement so that you don't get tied into one system or platform. that can be bad because it closes a site off - especially if "everywhere else" on the web isn't forcing a proprietary system on people to work with. LJ'ers are opened up to being more able to use generic clients that work on many blog platforms. Some clients allow posting to multiple sites/portals. To illustrate it a little, some LiveJournal users might have a separate journal for say recipes. Or they might have a blog on another site. People coming to LJ who've used a program to post elsewhere in the past can perhaps use the same program too. And no-one needs to stop using LJ features or do things in different ways.

One good thing about Atom and its being extensible is things like 'namespaces'. [_Very_] broadly speaking this means it can cope with supporting more generic things supported by lots of portals (e.g. trackback ping URLs, categories) and more specific things (e.g. LJ's moods + music, lj-cuts maybe) all in one go. Namespaces allow the browser/reader to just reference a file that says 'ok this is what that special command relates to; do this with it'. A site can have its own namespace or for widespread things there's a a "Dublin Core" namespace. An example is how TypePad allows categories so people can just view or subscribe to topics in a blog. So in their feeds it includes "dc:subject", for categories. That means any newsreader/webreader can cope with it and act on or ignore it as it needs, without breaking. LJ could have its own namespace too. The standards aspect - where possible - is good across all types of web content. It can help ensure webpages are usable in everything from lynx, screenreaders, and the lowliest handheld browser (such as a small browser on cellphone) to the most powerful desktop browser. Similarly, APIs in theory let developers do less trying to tweak things to support all different types of sites/content and more time making the product better.

The problem here is not some general extensibility etc. but if it is needed by anyone. There were requests for support of MT, in particular for at least basic functionality for crossposing to LJ and MT which is rather easy to make (just post/edit/delete/list categories), but many sites support Atom while LJ does not support MetaWeblog API (so I could not test with LJ) so it may be better to add support of Atom. Another problem is authentication and in Atom it is more secure without requirement of SSL.

Is there a way to delete old usernames in the log on screen? I looked around, but I couldn't find an entry already asking about this. Thanks.

See "Hide this username" in options

Would it make sense to support multiple alternative APIs

I'm not a LJ-client or 'blog-client in general coder, but I wonder if it would be possible, feasible, desirable to support multiple APIs. If the idea is to allow this client to as fully support as possible other types of weblogs and the like, as opposed to just providing the maximum possible support specifically for LJ-class blogs. Since some blogs might be best / most maximally supported using one API, while still others might be best supported by another API.

Presumably if you did this, you'd want to specify what API to use for each defined blog instance, on a per-blog basis.

Anyway. One being's musings. Hope this is of some use, interest. Thanks for your time. Be well.

-- Joseph

Re: Would it make sense to support multiple alternative APIs

Currently it fully supports LJ API and with small changes (most of which I already made since this poll) it will support most of other blog sites.

Excuse me for offtopic.

Readme file says: "Ctrl+D - Clear draft", but it doesn't work...

That is a shortcut for the red cross button near green icons of loading/saving drafts, it deletes the manually saved draft file from disk.

Hiya. I know this isn't really a support forum for Semagic, but I was hoping you'd be able to help me out here anyway. This also might be a bug, I'm not sure:

I use iTunes, and prior to installing Winamp I had Semagic detecting the music I was playing just fine. Now it doesn't, and in the status bar it says "Player: Winamp" when I try to detect. That's not my music player, and it's not even installed anymore. How can I fix this?

that means that plugin in itunes for music detection emulates winamp so old clients that supported only winamp can detect music in itunes. the error it only if it does not detect music.