||[Dec. 8th, 2007|11:01 am]
AFAIU, most of code in typical blogging engine deals with information presentation (correct me if I am wrong). Should we for distributed bloging some existing engine such as that of LJ or some engine for standalone blogging, or should we develop our own presentation engine? (The latter seems unfeasible due to development time considerations).|
I think that there should be many different, but interopreable distributed blogging engines.
Writing information presentation engine is easy. What is hard is to write information presentation engine which could bear load of several millions users. But distributed nature of our project makes it unnesseccary.
Existence of different engines within one social network starts competition. And competition is the good thing.
Once we have a functioning network with sdandartized protocols, multiple implementations are sure to appear. However, at present it is our task to make such network reality, and for it we need to get one working engine.
I think building on top of LJ engine is a good way to have a good (and useful) reference implementation.
Там GPL. (Я думаю, GPL это не так страшно - она разрешает закрытые модификации для внутреннего употребления).
I doubt so. LJ engine is an old perl codebase, full of ugly performance hacks.
It would be too difficult to read and understand it. It could be much easier to write working engine
using cleanroom method (take only functionality specification to meet from LJ).
The more I think about it, the more truth I see in rushatter
's words. Perhaps, the better way is to ensure the interoperability of the existing engines and packages... This is where the things are moving, with APP, OpenID and a whole bunch of other technologies. At the very least, it is worth my while to spend some time learning the state of art in these technologies, which is what I intend to do.
And yes, you are absolutely correct. LJ is a mess. I haven't seen Vox's server side sources, but its HTML looks like marvel compared to that of LJ.
I have not seen the LJ source code, but its external behavior suggests that it it based on a custom extension (
<lj user="">) of a subset (no
HEAD, no scripts, no frames, no forms except for commercial users) of HTML (more specifically, “tag soup”), and has a component that does some rudimentary formatting (
s/\n/<br>/ unless $do_not_autoformat) and strips out restricted elements and attributes. This is not the representation we should be willing to inherit.
I propose that the interchange format be based on a safe subset (no scripting) of XHTML (so that all implementors do not have to invent another interpretation of tag soup) Transitional DTD (because end users are not likely to learn the difference between
<b> and the importance of semantic markup). Then presentation layer becomes a simple matter of XSLT transformations and allows for (relatively) easy styling via CSS. Posting/commenting agent implementors are free to develop any conversion algorithms for other forms of input from end users — plain text, HTML, XHTML, BBCode, wiki markup, or whatever else — as long as they output valid XHTML to replication agents.
I'm all for such a clean and elegant solution (I have take a sort of twisted liking to XSLT), would it not for the desire to support the existing users, who are, for the most part, located on LJ-compliant services. Or maybe not? Actually, I think I've read somewhere that blogger.com is #1 now.
A converter would be necessary for moving an existing base. Probably there are existing html-to-xml converters which can be adopted to support lj extensions.
there are existing html-to-xml converters
Not that I'm aware of (though plenty of those that work in the opposite direction).
In fact there are. HTML Tidy
is a utility and a library that converts not-quite-valid HTML into vaild HTML or XHTML. It even has an option to replace presentational markup with CSS rules and allows definition of extension elements. I’ve seen it recommended in RU.XML FidoNet echo as a default solution for cases when there is HTML input and XML processing is desired.
( LJ autoformatter also converts (what looks like) URLs from
s/\n/<br> unless $do_not_autoformat)