From the first days of Ubuntu One, before we were even in Ubuntu, we've
had a structured data storage sync service based around CouchDB.
For the last three years we have worked with the company behind CouchDB
to make it scale in the particular ways we need it to scale in our
server environment. Our situation is rather unique, and we were unable
to resolve some of the issues we came across. We were thus unable to
make CouchDB scale up to the millions of users and databases we have in
our datacentres, and furthermore we were unable to make it scale down to
be a reasonable load on small client machines.
Because of this, we are turning off most of our CouchDB-related
efforts. The contacts, notes and playlists databases will continue to
exist on our servers to support the related services, but direct
external access to the underlying databases will be shut off. Any other
databases will be deleted from our servers entirely.
For these same three years we have created and maintained desktopcouch,
which is a desktop service (and related library) to access CouchDB more
conveniently. Because we are no longer going to pursue CouchDB, we will
no longer be developing desktopcouch; in fact, if anybody wants to take
over, we'll be happy to work with you to make that official. For the
upcoming 12.04 the Ubuntu One packages will not depend on desktopcouch
nor couchdb in any way, and we'd recommend the distribution seriously
consider whether they want to continue having the package in main,
especially if no maintainer shows up.
Because we still believe there is a lot of value to our users in the
service we wanted to offer based on CouchDB, we're building something
new, based on what we've learned. It's very small, merely a layer of
abstraction and the definition of an API that will allow us and others
to build what is needed ontop of existing tools. We're calling it U1DB
for now, until it comes of age. If you're interested and techincally
inclined you can follow our progress on lp:u1db; unfortunately our
timing and resources are such that we can only promise the reference
python implementation will be ready in time for 12.04, and thus 12.04
will ship without Ubuntu One having a solid story around synchronizing
arbitrary structured data.
Thank you for reading.
--
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
11-22-2011, 12:20 PM
Jo-Erlend Schinstad
EOL for couchdb and desktopcouch
Den 21. nov. 2011 12:48, skrev John Rowland Lenton:
For these same three years we have created and maintained desktopcouch,
which is a desktop service (and related library) to access CouchDB more
conveniently. Because we are no longer going to pursue CouchDB, we will
no longer be developing desktopcouch; in fact, if anybody wants to take
over, we'll be happy to work with you to make that official. For the
upcoming 12.04 the Ubuntu One packages will not depend on desktopcouch
nor couchdb in any way, and we'd recommend the distribution seriously
consider whether they want to continue having the package in main,
especially if no maintainer shows up.
I'm rather dismayed by this, I have to say. First you convince
developers to rely on your infrastructure for their apps, and then, out
of the blue, you remove key parts of it? It's not the first time,
either. One thing is removing it from Ubuntu One. If you can't manage
the large amounts of users and data, then that means U1 shouldn't have
been taken out of beta and that it in no way is ready for general use.
This is another example of Canonical showing poor judgement in its
communication.
However, removing support for tools that apps depend upon to store and
retrieve data locally is something else entirely. It is incomprehensible
to me that you would even consider this. If you want to attract
developers, then you simply cannot just remove tools that developers
depend upon. Storage infrastructure is a fairly critical part of most
computer systems. If you can't rely on that, then how on earth can you
expect people to invest time and money in developing for Ubuntu? I've
spent months on my app, and now it's lost most of it's value, if not
all. I'll have to re-write it from scratch. Should I add support for
Unity at all, or might that also suddenly be dropped? This is not the
way to create enthusiasm. Except for SSO, the database functionality was
the one big USP that Ubuntu One had. Speaking of SSO... We can't know
what's going on internally in Canonical, but we know for a fact that it
is willing to drop support without warning. This is a very good reason
not to rely on Ubuntu SSO for anything. After all, who knows if it'll be
there tomorrow? It is really sad to see myself writing something like
that. It's what Windows users use as an argument for sticking to Windows.
You're not only making fools of developers, however. You're also making
fools out of advocates. As late as yesterday, I wrote about Ubuntu
becoming a very attracting platform with focus on phones, tablets, etc.
One of the things I wrote about, was the ability to sync databases
between your devices, enabling you to keep working even when you're
offline. Yesterday, that symbolised the strength and potential of
Ubuntu. Today, the same thing symbolises uncertainty and unreliability.
I'm flabbergasted. This is not a wise decision.
Jo-Erlend Schinstad
--
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Tue Nov 22 15:30:01 2011
Return-path: <devel-bounces@lists.fedoraproject.org>
Envelope-to: tom@linux-archive.org
Delivery-date: Tue, 22 Nov 2011 15:21:20 +0200
Received: from bastion01.fedoraproject.org ([209.132.181.2]:33715 helo=bastion.fedoraproject.org)
by s2.java-tips.org with esmtp (Exim 4.69)
(envelope-from <devel-bounces@lists.fedoraproject.org>)
id 1RSqHo-0000Ez-AT
for tom@linux-archive.org; Tue, 22 Nov 2011 15:21:20 +0200
Received: from lists.fedoraproject.org (collab01.vpn.fedoraproject.org [192.168.1.21])
by bastion01.phx2.fedoraproject.org (Postfix) with ESMTP id 5DA7820FEA;
Tue, 22 Nov 2011 13:21:22 +0000 (UTC)
Received: from collab1.fedoraproject.org (localhost.localdomain [127.0.0.1])
by lists.fedoraproject.org (Postfix) with ESMTP id A3D35326760;
Tue, 22 Nov 2011 13:21:21 +0000 (UTC)
X-Original-To: devel@lists.fedoraproject.org
Delivered-To: devel@lists.fedoraproject.org
Received: from smtp-mm01.fedoraproject.org (smtp-mm01.fedoraproject.org
[80.239.156.217])
by lists.fedoraproject.org (Postfix) with ESMTP id 57F423266EF
for <devel@lists.fedoraproject.org>;
Tue, 22 Nov 2011 13:21:19 +0000 (UTC)
Received: from mail-fx0-f45.google.com (mail-fx0-f45.google.com
[209.85.161.45])
by smtp-mm01.fedoraproject.org (Postfix) with ESMTP id 81C0B87E5F
for <devel@lists.fedoraproject.org>;
Tue, 22 Nov 2011 13:21:18 +0000 (UTC)
Received: by faas14 with SMTP id s14so451493faa.32
for <devel@lists.fedoraproject.org>;
Tue, 22 Nov 2011 05:21:17 -0800 (PST)
Received: by 10.204.130.140 with SMTP id t12mr19336533bks.136.1321968077669;
Tue, 22 Nov 2011 05:21:17 -0800 (PST)
Received: from valhalla.rhi.hi.is (valhalla.rhi.hi.is. [130.208.69.191])
by mx.google.com with ESMTPS id z15sm10070678bkv.4.2011.11.22.05.21.15
(version=SSLv3 cipher=OTHER); Tue, 22 Nov 2011 05:21:16 -0800 (PST)
Message-ID: <4ECBA1CB.10308@gmail.com>
Date: Tue, 22 Nov 2011 13:21:15 +0000
From: =?UTF-8?B?IkrDs2hhbm4gQi4gR3XDsG11bmRzc29uIg==?=
<johannbg@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
rv:8.0) Gecko/20111115 Thunderbird/8.0
MIME-Version: 1.0
To: devel@lists.fedoraproject.org
Subject: Re: Fedora clean up process seems to be seriously broken...
References: <c46ceda3-0800-4691-9ced-1dc89295e187@zmail13.collab.prod.int.phx2.redhat.c om>
In-Reply-To: <c46ceda3-0800-4691-9ced-1dc89295e187@zmail13.collab.prod.int.phx2.redhat.c om>
X-BeenThere: devel@lists.fedoraproject.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Development discussions related to Fedora
<devel@lists.fedoraproject.org>
List-Id: Development discussions related to Fedora
<devel.lists.fedoraproject.org>
List-Unsubscribe: <https://admin.fedoraproject.org/mailman/listinfo/devel>,
<mailto:devel-request@lists.fedoraproject.org?subject=unsubscrib e>
List-Archive: <http://lists.fedoraproject.org/pipermail/devel>
List-Post: <mailto:devel@lists.fedoraproject.org>
List-Help: <mailto:devel-request@lists.fedoraproject.org?subject=help>
List-Subscribe: <https://admin.fedoraproject.org/mailman/listinfo/devel>,
<mailto:devel-request@lists.fedoraproject.org?subject=subscribe>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: devel-bounces@lists.fedoraproject.org
Errors-To: devel-bounces@lists.fedoraproject.org
> I'm rather dismayed by this, I have to say. First you convince developers to
> rely on your infrastructure for their apps, and then, out of the blue, you
> remove key parts of it? It's not the first time, either. One thing is
> removing it from Ubuntu One. If you can't manage the large amounts of users
> and data, then that means U1 shouldn't have been taken out of beta and that
> it in no way is ready for general use. This is another example of Canonical
> showing poor judgement in its communication.
In fairness to the original idea of using couchdb it is a great idea
and showed a lot of promise and it was a fair amount of time ago that
the choice was made to use it and between that time they got it to a
state where it was doing more or less what they had envisioned. The
problem here is there is no other company using couchdb at this scale
and there is a point where its not quite feasible to keep it going.
This isn't canonical flip flopping between technologies on a whim its
the scales of feasibility tipping to the wrong side.
> However, removing support for tools that apps depend upon to store and
> retrieve data locally is something else entirely. It is incomprehensible to
> me that you would even consider this. If you want to attract developers,
> then you simply cannot just remove tools that developers depend upon.
> Storage infrastructure is a fairly critical part of most computer systems.
> If you can't rely on that, then how on earth can you expect people to invest
> time and money in developing for Ubuntu? I've spent months on my app, and
> now it's lost most of it's value, if not all. I'll have to re-write it from
> scratch. Should I add support for Unity at all, or might that also suddenly
> be dropped? This is not the way to create enthusiasm. Except for SSO, the
> database functionality was the one big USP that Ubuntu One had. Speaking of
> SSO... We can't know what's going on internally in Canonical, but we know
> for a fact that it is willing to drop support without warning. This is a
> very good reason not to rely on Ubuntu SSO for anything. After all, who
> knows if it'll be there tomorrow? It is really sad to see myself writing
> something like that. It's what Windows users use as an argument for sticking
> to Windows.
I know what you mean here there are a few apps using it but if you
think about it wouldn't you cause inconvenience to a small minority
(and yes it is a bit of a minority using desktopcouch at the moment)
to improve the scalability and sustainability and pick or make
something that is a lot more suited to the task. That is the choice
that they had to make. Personally I had nothing to do with the
decision and im not even going to pretend that but its really
important to read the EOL email with care and see it from the business
point of view that they had to make a choice and do it before they ran
into serious issues.
> You're not only making fools of developers, however. You're also making
> fools out of advocates. As late as yesterday, I wrote about Ubuntu becoming
> a very attracting platform with focus on phones, tablets, etc. One of the
> things I wrote about, was the ability to sync databases between your
> devices, enabling you to keep working even when you're offline. Yesterday,
> that symbolised the strength and potential of Ubuntu. Today, the same thing
> symbolises uncertainty and unreliability.
>
> I'm flabbergasted. This is not a wise decision.
Deprecating things is a natural process of development. Out with the
old and in with the more suited until something different comes along
that is better its a cycle. It might seem rash and I know the
disappointment but still its something natural that happens to systems
over time things have to change before you hit the wall and you run
into an issue when thousands of programs depend on a library that is
fundamentally flawed and you have to ship it rather than break too
many things. The truth is the sooner the better that they pushed out
couchdb.
Regards
Shane
--
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
11-22-2011, 02:13 PM
Jo-Erlend Schinstad
EOL for couchdb and desktopcouch
Den 22. nov. 2011 15:09, skrev Shane Fagan:
In fairness to the original idea of using couchdb it is a great idea
and showed a lot of promise and it was a fair amount of time ago that
the choice was made to use it and between that time they got it to a
state where it was doing more or less what they had envisioned. The
problem here is there is no other company using couchdb at this scale
and there is a point where its not quite feasible to keep it going.
This isn't canonical flip flopping between technologies on a whim its
the scales of feasibility tipping to the wrong side.
That would be a very good reason to keep it in beta. It is usually a
good idea to test things before you release them to the public. By
announcing Ubuntu One as stable, reliable and available, they've fooled
people into spending time and money on something that isn't real.
I know what you mean here there are a few apps using it but if you
think about it wouldn't you cause inconvenience to a small minority
(and yes it is a bit of a minority using desktopcouch at the moment)
to improve the scalability and sustainability and pick or make
something that is a lot more suited to the task. That is the choice
that they had to make. Personally I had nothing to do with the
decision and im not even going to pretend that but its really
important to read the EOL email with care and see it from the business
point of view that they had to make a choice and do it before they ran
into serious issues.
Would I tear down an infrastructure that I had convinced a lot of people
to rely on before I had something to replace it with? Absolutely not.
Not in my wildest dreams. They show a level of respect that would fit
between the strings of the worlds smallest violin.
Deprecating things is a natural process of development. Out with the
old and in with the more suited until something different comes along
that is better its a cycle. It might seem rash and I know the
disappointment but still its something natural that happens to systems
over time things have to change before you hit the wall and you run
into an issue when thousands of programs depend on a library that is
fundamentally flawed and you have to ship it rather than break too
many things. The truth is the sooner the better that they pushed out
couchdb.
Are you saying that DesktopCouch is fundamentally flawed, or are you
saying that Ubuntu One is fundamentally flawed? Because those are
different things. You talk about natural deprecation of old
technologies. But you are describing something entirely different than
the actual situation. In your scenario, you're replacing a technology to
provide a feature with something else. That's not the case here. They're
removing the feature altogether, deleting databases. Some time in the
future, we might see a replacement, though the claim seems completely
unreasonable to me -- irrational, even. They claim that they can't make
CouchDB in Ubuntu scale, so they need to replace it with something that
will handle all platforms and all databases, which obviously includes
CouchDB. Seems to me that they're saying it was too difficult to learn
how to ride a bicycle with training wheels, so now they're joining the
Tour de France.
I've lost confidence. I don't believe a word of it. And that's sad.
Jo-Erlend Schinstad
--
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
11-22-2011, 02:44 PM
Shane Fagan
EOL for couchdb and desktopcouch
> That would be a very good reason to keep it in beta. It is usually a good
> idea to test things before you release them to the public. By announcing
> Ubuntu One as stable, reliable and available, they've fooled people into
> spending time and money on something that isn't real.
It was working to the point where it couldnt really be called beta
software. It always had the odd sticky issue but they spent hard
earned time and money making it get to the point where it was pretty
stable. The issue is scalability and that is a flaw that can only be
discovered when you hit the ceiling and you have to fight to either
keep the thing going and maintaining the service or replace it.
> Would I tear down an infrastructure that I had convinced a lot of people to
> rely on before I had something to replace it with? Absolutely not. Not in my
> wildest dreams. They show a level of respect that would fit between the
> strings of the worlds smallest violin.
Think of it like a bridge if there was a bridge that was built for 200
cars to go across and you hit 200 pretty consistently and you forecast
that its only going to get worse you would upgrade and build a
stronger one by replacing it or strengthening it. Strengthening it
only takes it so far maybe up to 500 but what happens after that?
Couchdb was never tested on the level that its at currently and its
struggling what happens when you get to the 200 million Mark said he
wants? It wouldn't be feasible to keep it going. So by replacing it
now before it gets to the point where too many people are relying on
it they are saving a good lot of hassle in the future.
Oh and im not arguing about the deleting of databases I don't really
know what the story is on that or if its possible to migrate it over
or if it would be better just to start clean.
> Are you saying that DesktopCouch is fundamentally flawed, or are you saying
> that Ubuntu One is fundamentally flawed? Because those are different things.
> You talk about natural deprecation of old technologies. But you are
> describing something entirely different than the actual situation. In your
> scenario, you're replacing a technology to provide a feature with something
> else. That's not the case here. They're removing the feature altogether,
> deleting databases. Some time in the future, we might see a replacement,
> though the claim seems completely unreasonable to me -- irrational, even.
> They claim that they can't make CouchDB in Ubuntu scale, so they need to
> replace it with something that will handle all platforms and all databases,
> which obviously includes CouchDB. Seems to me that they're saying it was too
> difficult to learn how to ride a bicycle with training wheels, so now
> they're joining the Tour de France.
Im saying couchdb is fundamentally flawed by the fact that there are
problems with how scalable it is. That warrants changing it because at
the numbers that are needed to sustain much more people wouldn't work.
And im pretty sure you didn't read all of that email they are making
something similar to replace it here is the quote just for
clarification.
"Because we still believe there is a lot of value to our users in the
service we wanted to offer based on CouchDB, we're building something
new, based on what we've learned. It's very small, merely a layer of
abstraction and the definition of an API that will allow us and others
to build what is needed ontop of existing tools. We're calling it U1DB
for now, until it comes of age. If you're interested and techincally
inclined you can follow our progress on lp:u1db; unfortunately our
timing and resources are such that we can only promise the reference
python implementation will be ready in time for 12.04, and thus 12.04
will ship without Ubuntu One having a solid story around synchronizing
arbitrary structured data."
So you aren't getting left high and dry.
Shane
--
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
11-22-2011, 02:45 PM
John Rowland Lenton
EOL for couchdb and desktopcouch
On Tue, 22 Nov 2011 14:20:41 +0100, Jo-Erlend Schinstad <joerlend.schinstad@gmail.com> wrote:
>
> I'm rather dismayed by this, I have to say.
I can imagine. We (Ubuntu One) tried as much as we could (beyond what
some would call reasonable) to not have to come to this end, but, as I
said, we could find no credible way forwards. This has been a very
painful decision to reach.
> First you convince
> developers to rely on your infrastructure for their apps, and then, out
> of the blue, you remove key parts of it?
it wasn't working. That's the whole point.
> It's not the first time, either.
I don't think we've removed developer-facing features before. We've
removed services when they didn't work. I *might* be forgetting
something, but I think not. Obviously.
> One thing is removing it from Ubuntu One. If you can't manage
> the large amounts of users and data, then that means U1 shouldn't have
> been taken out of beta and that it in no way is ready for general use.
A reasonable point. Which I disagree with, at several levels, but I
don't think this is the place to get into that.
> This is another example of Canonical showing poor judgement in its
> communication.
communication is hard. Again, I disagree that this particular instance
was an example of us struggling to communicate; I think you're reading
more and less from my email than what I thought I was putting into
it.
> However, removing support for tools that apps depend upon to store and
> retrieve data locally is something else entirely. It is incomprehensible
> to me that you would even consider this.
I don't know where you got the impression I or we were proposing or
suggesting that the distribution do that.
Ubuntu One, as upstream of desktopcouch, is letting Ubuntu know that
we're not going to go on working on desktopcouch, and the service is
going away from our servers. This is the next step after letting the
more prominent stakeholders know in person at UDS.
> We can't know
> what's going on internally in Canonical, but we know for a fact that it
> is willing to drop support without warning.
The email you responded to was the warning. Had you talked with the
Ubuntu One developers at UDS or since then, we would've told you. We
individually talked with the main stakeholders at or before UDS. We had
U1DB sessions at UDS, and we have openly talked about the status of
couchdb with developers since around that time.
> You're not only making fools of developers, however. You're also making
> fools out of advocates. As late as yesterday, I wrote about Ubuntu
> becoming a very attracting platform with focus on phones, tablets, etc.
> One of the things I wrote about, was the ability to sync databases
> between your devices, enabling you to keep working even when you're
> offline. Yesterday, that symbolised the strength and potential of
> Ubuntu. Today, the same thing symbolises uncertainty and unreliability.
It's interesting that you mention this, because the drive to enable
Ubuntu to be that platform is one of the things that is pushing us to
fix things. CouchDB wasn't working for us to do what we and you want to
do with the platform, so we're swapping the component out for one that
*will* work.
Thank you for caring,
--
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
11-22-2011, 03:17 PM
Rick Spencer
EOL for couchdb and desktopcouch
On 11/22/2011 04:45 PM, John Rowland Lenton wrote:
First you convince
developers to rely on your infrastructure for their apps, and then, out
of the blue, you remove key parts of it?
it wasn't working. That's the whole point.
I strongly agree with this. I think I've probably written more
desktop-couch code than anyone outside the Online Services team.
DesktopCouch performance on the client, and failures to sync on the
server have been have both major thorns in my side. Not to mention
suffering through writing javascript map/reduce statements, ug!
I, therefore, welcome this move. I really want the ability to have a
local but synced store with an easy API, but DesktopCouch was just not
able to provide this. I am very grateful that the team is going to apply
what's been learned to a new generation of such functionality, and I
will be the first to write a DictionaryGrid that uses it!
Cheers, Rick
It's not the first time, either.
I don't think we've removed developer-facing features before. We've
removed services when they didn't work. I *might* be forgetting
something, but I think not. Obviously.
One thing is removing it from Ubuntu One. If you can't manage
the large amounts of users and data, then that means U1 shouldn't have
been taken out of beta and that it in no way is ready for general use.
A reasonable point. Which I disagree with, at several levels, but I
don't think this is the place to get into that.
This is another example of Canonical showing poor judgement in its
communication.
communication is hard. Again, I disagree that this particular instance
was an example of us struggling to communicate; I think you're reading
more and less from my email than what I thought I was putting into
it.
However, removing support for tools that apps depend upon to store and
retrieve data locally is something else entirely. It is incomprehensible
to me that you would even consider this.
I don't know where you got the impression I or we were proposing or
suggesting that the distribution do that.
Ubuntu One, as upstream of desktopcouch, is letting Ubuntu know that
we're not going to go on working on desktopcouch, and the service is
going away from our servers. This is the next step after letting the
more prominent stakeholders know in person at UDS.
We can't know
what's going on internally in Canonical, but we know for a fact that it
is willing to drop support without warning.
The email you responded to was the warning. Had you talked with the
Ubuntu One developers at UDS or since then, we would've told you. We
individually talked with the main stakeholders at or before UDS. We had
U1DB sessions at UDS, and we have openly talked about the status of
couchdb with developers since around that time.
You're not only making fools of developers, however. You're also making
fools out of advocates. As late as yesterday, I wrote about Ubuntu
becoming a very attracting platform with focus on phones, tablets, etc.
One of the things I wrote about, was the ability to sync databases
between your devices, enabling you to keep working even when you're
offline. Yesterday, that symbolised the strength and potential of
Ubuntu. Today, the same thing symbolises uncertainty and unreliability.
It's interesting that you mention this, because the drive to enable
Ubuntu to be that platform is one of the things that is pushing us to
fix things. CouchDB wasn't working for us to do what we and you want to
do with the platform, so we're swapping the component out for one that
*will* work.
Thank you for caring,
--
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
11-22-2011, 04:11 PM
Jo-Erlend Schinstad
EOL for couchdb and desktopcouch
Den 22. nov. 2011 16:45, skrev John Rowland Lenton:
I don't know where you got the impression I or we were proposing or
suggesting that the distribution do that. Ubuntu One, as upstream of
desktopcouch, is letting Ubuntu know that we're not going to go on
working on desktopcouch, and the service is going away from our
servers. This is the next step after letting the more prominent
stakeholders know in person at UDS.
Well, in your original email, you did recommend that it be moved out of
main, didn't you? Coming from a developer who is both the upstream and
the primary distro sponsor, how do you think the audience -- who happens
to be the app developers you seek to attract -- should interpret it?
The email you responded to was the warning. Had you talked with the
Ubuntu One developers at UDS or since then, we would've told you. We
individually talked with the main stakeholders at or before UDS. We had
U1DB sessions at UDS, and we have openly talked about the status of
couchdb with developers since around that time.
I hadn't actually considered DesktopCouch to be dependent on Ubuntu One.
I considered Ubuntu Ones database synchronization service to be
dependent on the DesktopCouch, but not vice versa. Much the same way, I
don't expect my home directory to be dependent on Ubuntu One file
synchronization service.
While I can understand the reasons why you feel it necessary to pull the
plug on the db sync service, it is not immediately obvious to me why
that would necessarily result in you dropping support for local storage
in personal databases on the desktop. I don't see anything wrong with
DesktopCouch itself. By the way, what is going to happen with the
server-side software that you're now abandoning? Will you GPL it and
release it so that others can benefit from the work? After all, even if
you couldn't make it scale to millions of databases, it might still be
useful as a residential sync service, for example.
It's interesting that you mention this, because the drive to enable
Ubuntu to be that platform is one of the things that is pushing us to
fix things. CouchDB wasn't working for us to do what we and you want to
do with the platform, so we're swapping the component out for one that
*will* work.
No, I don't think our goals are the same. My goal is to create software
using tools that are available for many platforms, such as Python, GTK
and CouchDB. I would then like to enable the users to sync their data
between all their devices, across platforms. Your goal is similar, but
from a completely different perspective. You want to build a public
service for millions and millions of users. That makes sense to you,
because that's your business. But it doesn't make sense to me, because
most families and businesses doesn't have millions of members. From my
perspective, the stack I referred to earlier, which you until very
recently have been advocating, _does_ work.
Tell me you're going to GPL and release your server-side db-sync stuff,
and I'll have all my enthusiasm back and stop nagging.
Thank you for caring,
Likewise.
Jo-Erlend Schinstad
--
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
11-22-2011, 04:36 PM
John Rowland Lenton
EOL for couchdb and desktopcouch
On Tue, 22 Nov 2011 18:11:40 +0100, Jo-Erlend Schinstad <joerlend.schinstad@gmail.com> wrote:
> I hadn't actually considered DesktopCouch to be dependent on Ubuntu One.
> I considered Ubuntu Ones database synchronization service to be
> dependent on the DesktopCouch, but not vice versa. Much the same way, I
> don't expect my home directory to be dependent on Ubuntu One file
> synchronization service.
people will still be able to install desktopcouch and couchdb-bin and
use it as they could now, either locally or syncing peer-to-peer with
the bluetoothish pairing tool (desktopcouch-pair, from package
desktopcouch-tools) we wrote for that use case. I don't understand what
upsets you so much about it being in universe instead of main.
> While I can understand the reasons why you feel it necessary to pull the
> plug on the db sync service, it is not immediately obvious to me why
> that would necessarily result in you dropping support for local storage
> in personal databases on the desktop. I don't see anything wrong with
> DesktopCouch itself.
the problems on the desktop are more evident on smaller devices
> By the way, what is going to happen with the
> server-side software that you're now abandoning? Will you GPL it and
> release it so that others can benefit from the work? After all, even if
> you couldn't make it scale to millions of databases, it might still be
> useful as a residential sync service, for example.
our server database was apache couchdb, plus a couple of patches written
for us by couchio/couchbase/membase that they didn't think were
generally reusable outside of our datacentre (and require significant
rework to apply to newer couches)
> My goal is to create software
> using tools that are available for many platforms, such as Python, GTK
> and CouchDB. I would then like to enable the users to sync their data
> between all their devices, across platforms. [...] From my
> perspective, the stack I referred to earlier, which you until very
> recently have been advocating, _does_ work.
and there's no reason for you not to use it, if it works for you.
> Tell me you're going to GPL and release your server-side db-sync stuff,
> and I'll have all my enthusiasm back and stop nagging.
it really is just apache couchdb.
--
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
11-22-2011, 04:47 PM
Allison Randal
EOL for couchdb and desktopcouch
On 11/22/2011 09:11 AM, Jo-Erlend Schinstad wrote:
> While I can understand the reasons why you feel it necessary to pull the
> plug on the db sync service, it is not immediately obvious to me why
> that would necessarily result in you dropping support for local storage
> in personal databases on the desktop. I don't see anything wrong with
> DesktopCouch itself.
So, it sounds like you might be interested in adopting maintenance of
desktopcouch? This is a pretty standard practice in free software,
Debian even has an official process for it ("Packages up for adoption").
You've got a vision for where to take it next, so if you have time and
interest, it could be a perfect match.
Allison
--
ubuntu-desktop mailing list
ubuntu-desktop@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
EOL for couchdb and desktopcouch
