איש אי הכלבים

Если бы LJ предоставлял более открытый интерфейс, то любые из вышеперечисленных, а также множество других хороших предложений можно было бы реализовать в LJ-клиенте. Сейчас под клиентом понимается только программа для добавления записей и простейшего администрирования, увы :(

Существует такое множество различных и взаимоисключающих предложений по развитию LJ, что единственным выходом развития LJ я вижу создание клиентов-браузеров на базе какого-нибудь "LiveJournal API".

Хотя, в принципе, это можно начать делать и сегодня...

From:

Ценность ЖЖ – в его населении (банальность, да), поэтому некоторую умеренную уёжищность его с технической точки зрения я лично ему легко прощаю. Что касается реализации предложений, подобных описанному, я специально оговариваю, что дополнительная информация будет храниться на клиенте.

Универсальный блог-сервер с открытым API… Ещё и JXTA какое-нибудь добавить… Не в этой, похоже, жизни. Вот аська, кстати, тоже ещё то уёжище.

From:

Ценность ЖЖ – в его населении
Именно. Поэтому, на мой взгляд, единственное, чего ему не хватает - это открытого API. И все были бы счастливы :)

дополнительная информация будет храниться на клиенте
Это уже детали. Ее можно хранить на специальном сервере, чтобы не было привязки к машине.

Не в этой, похоже, жизни.
Увы, согласен.

From:

Кстати, уж дополнительную-то информацию, хранимую сервером и интерпретируемую клиентским софтом, реализовать даже в рамках нынешнего подхода легче лёгкого.

From:

легче лёгкого
Так, может, вперед?

Я как-то даже начал писать такой клиент, и он даже немного работал :)

From:

Я имел в виду, что какая-т поддержка сервера нужна. Типа HTTP cookies, только наоборот. Application-specific data associated with various LJ objects. То есть:

package com.livejournal.api;

public interface DataHolder {
  public void setData(String dataURI, Object cargo) throws Exception;
  public Object getData(String dataURI) throws Exception;
}

public class User … implements DataHolder { … }

public class Friend … implements DataHolder { … }

public class FriendGroup … implements DataHolder { … }

public class Post … implements DataHolder { … }

public class Comment … implements DataHolder { … }

public class MemorablePost … implements DataHolder { … }

Если не хранить данные на сервере, невозможно обеспечить client location transparency.

From:

Совершенно не обязательно хранить дополнительные данные на серверах LJ. Можно использовать другой (свой) сервер.

Так что действительно можно начинать прямо сейчас.

From:

А если мы соберёмся уходить в седьмую, извините, зону, за нами никто не пойдёт. И будем мы там сидеть как маленькая толпа уродов на journals.ru каких-нибудь.

From:

в седьмую, извините, зону
А это, извините, что такое?

за нами никто не пойдёт
Я сам туда не пойду :)

From:

А это, извините, что такое?

Фидошное. Из-за каких-то забытых ныне проблем мятежники во главе с Завалишиным собирались организовывать зону 7 вместо региона 2:50. И то, и другое означало Россию. Типа автокефальная церковь и всё такое. Кончилось, естественно, ничем.

From:

прочитал про гипергруппы. верной тропинкой идёте, товарищ! но слишком узкой (тропинкой). почему гипергруппы обязательно эксклюзивны?

прочитал "куда лучше формулировку". совсем ботва. из неё следует только, что у френдов есть свойства (surprise! surprise!).

а вот как надо

From:

Ты описываешь Общую Теорию Всего, а я пытаюсь понять, как нужно подпилить конкретный софт LJ, а ещё лучше – как, не подпиливая серверного софта, который всё равно Авва и Брэд хрен подпилят, приделать something helpful сбоку в качестве бантика. Данные, хранимые локально и отвязанные от всяческих кривых сервисов можно организовывать любыми outlinerами, метакаками и так далее. И фантазировать на эту тему. Кстати, интересно вы там перетираете. :)

Да, а в нынешнем LJ френды не имеют ни хера, поэтому всё это конечно же surprise, surprise. :)

From:

мы все трое обсуждаем, как приделать что-то сбоку, не трогая серверного софта. и я, на мой скромный :-) взгляд, предлагаю это сделать наименее криво. разница в трудозатратах же ничтожна, если вообще есть, и окупится первым же случаем, когда потребуется что-то, не предусмотренное более специфичным дизайном.

тем более, что не только разница в трудозатратах ничтожна, а и сами трудозатраты целиком.

From:

Ну, у тебя там формулировки, специально к ЖЖ не привязанные. Я и решил, что ты обдумываешь аутлайнер общего вида. Насчёт трудозатрат – это ты Сёме скажи. :)

From:

не, я обдумываю, как и сказал, общую теорию организации всего :-)

а аутлайнер и список френдов - конкретные приложения теории.

From:

Гипергруппы эксклюзивны, потому что у меня в голове в рамках данной задачи каждый объект однозначно классифицируется в пределах одной классификации. Человек не имеет двух степеней доверия или интересности. Именно поэтому, кстати, признаки, причём имеющие линейную метрическую семантику, я счёл лучшей формулировкой.

From:

ок, то есть у тебя только два уровня - группы и гипергруппы, причём первые и вторые - разные сущности (хотя отличаются они только значением свойства exclusive=true/false). а если две гипергруппы захочется почему-нибудь объединить?

From:

На самом деле я повёл себя, как поклонник сурового бога Yagni. Что мне прямо сейчас нужно – это атрибуты. Поэтому формулировка "через свойства" показалась мне более адекватной. На вопрос "supposing we want to move all LJ friends with trust level 0 to trust level 1…" я отвечу винни-пуховским "supposing we don't", потому что в моей реальной практике обращения с предметами операции типа "update T set a=1 where a=0" не встречаются. Из программистского опыта я знаю, что такие операции означают обычно изменения в метамодели – но это уже форс-мажор.

From: