Home » Modeling » EMF » what is a resource?
|
| Re: what is a resource? [message #420008 is a reply to message #420007] |
Tue, 17 June 2008 11:16   |
|
Hi André,
Basically this is an EMF question but since the Resource plays a special
role in CDO here is the explanation (Ed might want to add):
Since EMF is strongly related to XSD/XML there is the notion of
containment and documents. An EMF Resource acts as the top level
container for an object tree and relates to something like an XML file.
It is like a container object with a URI. But in pure EMF it is not an
EObject!
In CDO a Resource is also an EObject! That makes it much easier to
persist the persistent properties (URI and contents) much like any other
persistent EObject.From this perspective CDOResources are like *named
entry points* into the forrest of persistent objects (CDOObjects).
In the RDBMS world it is simply a row in a table that was mapped for the
class CDOResource.
Cheers
/Eike
André Dietisheim schrieb:
> Hi Eike
>
> One further question:
> I did not get the whole idea of the concept of resources. What do you
> encapsulate into a resource? I understood so far that it's not the
> RDBMS equivalent to the schema, but what is it comparable to in the
> RDBMS world? What is the best practice here?
>
> Cheers + thanks!
> André
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
| |
| Re: [CDO] Re: what is a resource? [message #420096 is a reply to message #420093] |
Tue, 17 June 2008 16:46 |
 Andre Dietisheim
Messages: 131
Registered: July 2009 |
Senior Member |
|
|
Let me explain by a my use case I try to implement:
we'll have Db with different types of objets (locations, phone-numbers,
phones, etc.). If I get it right, this shall be the objects in the resource.
If I want to add a new location, I'll load resource and add an Object
(and the opposite when I remove).
But if a resource is mapped to a single row in CDO, I assume that this
is not the optimal to achieve these operations.
Cheers
André I
André Dietisheim wrote:
> Hi Eike,
>
> Thanks, that enligthens me... so a classical usage scenario (like adding
> records to a RDBMS) is adding/modifying/removing resources in CDO, right?
> Searching objects is done by iterating through records and searching the
> objects stored in it?
> As far as I understood CDO for now, you may put different types in a
> resource. Is there any good pratice to split objects to different
> resources?
>
> Cheers
> André
>
>
> Eike Stepper wrote:
>> Hi André,
>>
>> Basically this is an EMF question but since the Resource plays a
>> special role in CDO here is the explanation (Ed might want to add):
>>
>> Since EMF is strongly related to XSD/XML there is the notion of
>> containment and documents. An EMF Resource acts as the top level
>> container for an object tree and relates to something like an XML
>> file. It is like a container object with a URI. But in pure EMF it is
>> not an EObject!
>>
>> In CDO a Resource is also an EObject! That makes it much easier to
>> persist the persistent properties (URI and contents) much like any
>> other persistent EObject.From this perspective CDOResources are like
>> *named entry points* into the forrest of persistent objects (CDOObjects).
>>
>> In the RDBMS world it is simply a row in a table that was mapped for
>> the class CDOResource.
>>
>> Cheers
>> /Eike
>>
>>
>>
>> André Dietisheim schrieb:
>>> Hi Eike
>>>
>>> One further question:
>>> I did not get the whole idea of the concept of resources. What do you
>>> encapsulate into a resource? I understood so far that it's not the
>>> RDBMS equivalent to the schema, but what is it comparable to in the
>>> RDBMS world? What is the best practice here?
>>>
>>> Cheers + thanks!
>>> André
|
|
|
| Re: [CDO] Re: what is a resource? [message #420102 is a reply to message #420093] |
Wed, 18 June 2008 07:43 |
|
Hi André,
Comment below...
André Dietisheim schrieb:
> Hi Eike,
>
> Thanks, that enligthens me... so a classical usage scenario (like
> adding records to a RDBMS) is adding/modifying/removing resources in
> CDO, right?
yes, generally you add, modify and remove objects and object trees, but
resources are also objects ;-)
> Searching objects is done by iterating through records and searching
> the objects stored in it?
/model-centric vs. database-centric/:
I don't like the terms schemas, records, rows, columns, etc. very much
in conjunction with modeling ;-)
From a usual application's point of view there are models (packages)
and there are instances of these models (objects and resources).
Your application integrates with EMF to get access to these modeling
concepts. CDO integrates with EMF at client side to add the concepts of
transactionality and persistence.
CDO can transfer the EMF concepts and theCDO concepts over the network
to a model repository.
A CDO model repository must have a backend storage (IStore) configured
and it only depends on the implementation of this IStore how the EMF and
CDO concepts are mapped to persistent data (in the case of the MEMStore
this even doesn't need to be really persistent). This IStore can
implement a mapping to an RDB (through Hibernate or native JDBC), to a
flat file system, to an OODB and, and, and...
So, back to your question, "searching" (given that you mean "my
application searches") is primarily done by using the modeling concepts,
that is "navigating" through object graphs.
One out-of-the-box exception is loading a resource by giving an
externally well-known name.
Another exception is indeed server-side searching and Simon is working
on this topic.
It will at least partially be store-dependent, although we might be able
to have common query languages like ocl and xpath available in the core
repository as well.
Is this what you intended to ask?
> As far as I understood CDO for now, you may put different types in a
> resource.
What are "types" here? Do you mean object of different classes? Then,
yes ;-)
> Is there any good pratice to split objects to different resources?
Hmm, good question and surely not the first time this question comes up ;-)
For example in file based model persistence (the default with XML) you
quickly reach limits with huge resources and you naturally start
thinking about how to cut the object tree into separate containment
trees (==resources). I think it's mainly driven by the restriction of
lazy loading to non-containement references. Well, this is only
partially true since EMF has containment proxies nowadays, as well.
With CDO this basic restriction is no longer there for CDO native models
(derived from CDOObjectImpl).
*All* references, containment or not, are loaded on demand and are even
unloaded transparently on demand.
So the scalability characteristics also don't seem to make good
arguments for a certain strategy to partition the object tree.
At least as long as the query feature is not fully available I'd say the
best criterium is "Do I need random access to an object? Then I put it
into a named resource."
Btw. if you don't care to externally store an object ID (as you would
have to do for a resource path), you can also directly access objects by id.
Cheers
/Eike
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: [CDO] Re: what is a resource? [message #420103 is a reply to message #420096] |
Wed, 18 June 2008 07:46 |
|
André Dietisheim schrieb:
> Let me explain by a my use case I try to implement:
>
> we'll have Db with different types of objets (locations,
> phone-numbers, phones, etc.). If I get it right, this shall be the
> objects in the resource.
> If I want to add a new location, I'll load resource and add an Object
> (and the opposite when I remove).
See the other answer.
> But if a resource is mapped to a single row in CDO, I assume that this
> is not the optimal to achieve these operations.
Ah, this single row I mentioned is only for the resource instance
itself, excluded all reference targets (here: contents)!
Again, the backend storage depends onmany things like the store
implementation.
Cheers
/Eike
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: [CDO] Re: what is a resource? [message #420128 is a reply to message #420102] |
Wed, 18 June 2008 16:50 |
Andre Dietisheim
Messages: 131
Registered: July 2009 |
Senior Member |
|
|
Hi Eike
wow, extensive explanations. I'll have to switch context and in object
graphs instead of relational organisation of the data. What I try to
answer is if it's compliant to good (modelling/CDO) pratices to add all
my entity-instances to one resource. Does your experience teach you a
better approach? You'll for sure answer 'that depends' but a good few
hints would help a lot.
Thanks + Cheers
André
Eike Stepper wrote:
> Hi André,
>
> Comment below...
>
>
>
> André Dietisheim schrieb:
>> Hi Eike,
>>
>> Thanks, that enligthens me... so a classical usage scenario (like
>> adding records to a RDBMS) is adding/modifying/removing resources in
>> CDO, right?
> yes, generally you add, modify and remove objects and object trees, but
> resources are also objects ;-)
>
>> Searching objects is done by iterating through records and searching
>> the objects stored in it?
> /model-centric vs. database-centric/:
>
> I don't like the terms schemas, records, rows, columns, etc. very much
> in conjunction with modeling ;-)
> From a usual application's point of view there are models (packages)
> and there are instances of these models (objects and resources).
> Your application integrates with EMF to get access to these modeling
> concepts. CDO integrates with EMF at client side to add the concepts of
> transactionality and persistence.
> CDO can transfer the EMF concepts and theCDO concepts over the network
> to a model repository.
> A CDO model repository must have a backend storage (IStore) configured
> and it only depends on the implementation of this IStore how the EMF and
> CDO concepts are mapped to persistent data (in the case of the MEMStore
> this even doesn't need to be really persistent). This IStore can
> implement a mapping to an RDB (through Hibernate or native JDBC), to a
> flat file system, to an OODB and, and, and...
>
> So, back to your question, "searching" (given that you mean "my
> application searches") is primarily done by using the modeling concepts,
> that is "navigating" through object graphs.
> One out-of-the-box exception is loading a resource by giving an
> externally well-known name.
> Another exception is indeed server-side searching and Simon is working
> on this topic.
> It will at least partially be store-dependent, although we might be able
> to have common query languages like ocl and xpath available in the core
> repository as well.
>
> Is this what you intended to ask?
>
>
>> As far as I understood CDO for now, you may put different types in a
>> resource.
> What are "types" here? Do you mean object of different classes? Then,
> yes ;-)
>
>> Is there any good pratice to split objects to different resources?
> Hmm, good question and surely not the first time this question comes up ;-)
> For example in file based model persistence (the default with XML) you
> quickly reach limits with huge resources and you naturally start
> thinking about how to cut the object tree into separate containment
> trees (==resources). I think it's mainly driven by the restriction of
> lazy loading to non-containement references. Well, this is only
> partially true since EMF has containment proxies nowadays, as well.
> With CDO this basic restriction is no longer there for CDO native models
> (derived from CDOObjectImpl).
> *All* references, containment or not, are loaded on demand and are even
> unloaded transparently on demand.
> So the scalability characteristics also don't seem to make good
> arguments for a certain strategy to partition the object tree.
>
> At least as long as the query feature is not fully available I'd say the
> best criterium is "Do I need random access to an object? Then I put it
> into a named resource."
> Btw. if you don't care to externally store an object ID (as you would
> have to do for a resource path), you can also directly access objects by
> id.
>
> Cheers
> /Eike
>
|
|
|
| Re: [CDO] Re: what is a resource? [message #420130 is a reply to message #420128] |
Wed, 18 June 2008 17:16 |
|
André Dietisheim schrieb:
> Hi Eike
>
> wow, extensive explanations. I'll have to switch context and in object
> graphs instead of relational organisation of the data. What I try to
> answer is if it's compliant to good (modelling/CDO) pratices to add
> all my entity-instances to one resource. Does your experience teach
> you a better approach? You'll for sure answer 'that depends' but a
> good few hints would help a lot.
That depends ;-)
My tip:
Don't apply structure to anything until you discover an urgent need for
a certain structure.
If you structure something without requirements you run into danger that
the chosen structure doesn't meet the requirements when they come.
When you have requirements you'll know how to transform them into
appropriate design most of the time.
Too general?
Then I need more input ;-)
Cheers
/Eike
>
> Thanks + Cheers
> André
>
> Eike Stepper wrote:
>> Hi André,
>>
>> Comment below...
>>
>>
>>
>> André Dietisheim schrieb:
>>> Hi Eike,
>>>
>>> Thanks, that enligthens me... so a classical usage scenario (like
>>> adding records to a RDBMS) is adding/modifying/removing resources in
>>> CDO, right?
>> yes, generally you add, modify and remove objects and object trees,
>> but resources are also objects ;-)
>>
>>> Searching objects is done by iterating through records and searching
>>> the objects stored in it?
>> /model-centric vs. database-centric/:
>>
>> I don't like the terms schemas, records, rows, columns, etc. very
>> much in conjunction with modeling ;-)
>> From a usual application's point of view there are models (packages)
>> and there are instances of these models (objects and resources).
>> Your application integrates with EMF to get access to these modeling
>> concepts. CDO integrates with EMF at client side to add the concepts
>> of transactionality and persistence.
>> CDO can transfer the EMF concepts and theCDO concepts over the
>> network to a model repository.
>> A CDO model repository must have a backend storage (IStore)
>> configured and it only depends on the implementation of this IStore
>> how the EMF and CDO concepts are mapped to persistent data (in the
>> case of the MEMStore this even doesn't need to be really persistent).
>> This IStore can implement a mapping to an RDB (through Hibernate or
>> native JDBC), to a flat file system, to an OODB and, and, and...
>>
>> So, back to your question, "searching" (given that you mean "my
>> application searches") is primarily done by using the modeling
>> concepts, that is "navigating" through object graphs.
>> One out-of-the-box exception is loading a resource by giving an
>> externally well-known name.
>> Another exception is indeed server-side searching and Simon is
>> working on this topic.
>> It will at least partially be store-dependent, although we might be
>> able to have common query languages like ocl and xpath available in
>> the core repository as well.
>>
>> Is this what you intended to ask?
>>
>>
>>> As far as I understood CDO for now, you may put different types in a
>>> resource.
>> What are "types" here? Do you mean object of different classes? Then,
>> yes ;-)
>>
>>> Is there any good pratice to split objects to different resources?
>> Hmm, good question and surely not the first time this question comes
>> up ;-)
>> For example in file based model persistence (the default with XML)
>> you quickly reach limits with huge resources and you naturally start
>> thinking about how to cut the object tree into separate containment
>> trees (==resources). I think it's mainly driven by the restriction of
>> lazy loading to non-containement references. Well, this is only
>> partially true since EMF has containment proxies nowadays, as well.
>> With CDO this basic restriction is no longer there for CDO native
>> models (derived from CDOObjectImpl).
>> *All* references, containment or not, are loaded on demand and are
>> even unloaded transparently on demand.
>> So the scalability characteristics also don't seem to make good
>> arguments for a certain strategy to partition the object tree.
>>
>> At least as long as the query feature is not fully available I'd say
>> the best criterium is "Do I need random access to an object? Then I
>> put it into a named resource."
>> Btw. if you don't care to externally store an object ID (as you would
>> have to do for a resource path), you can also directly access objects
>> by id.
>>
>> Cheers
>> /Eike
>>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: [CDO] Re: what is a resource? [message #420132 is a reply to message #420130] |
Wed, 18 June 2008 17:31 |
Andre Dietisheim
Messages: 131
Registered: July 2009 |
Senior Member |
|
|
Hi Eike
I knew that it's for sure (and it does not depend) that you'll say that
it depends ;-) )
I worked mostly being database-centric and mapped that view to the
OO-world so far.
Good hint, not to apply any structure if it's not necessar, it follows
agile principles. So I'll probably start my putting all my model
instances to 1 resource.
To show my use case:
I'll have customers that own locations. Those locations will contains
phones and those phones will have features. That looks (to unexperienced
modeler I am) like a single resource that contains several customer
objects that have references to location-objects and so on.
I'll catch up as soon as I get more concrete data and requirements.
Thanks a lot so far!
Cheers
André
Eike Stepper wrote:
> André Dietisheim schrieb:
>> Hi Eike
>>
>> wow, extensive explanations. I'll have to switch context and in object
>> graphs instead of relational organisation of the data. What I try to
>> answer is if it's compliant to good (modelling/CDO) pratices to add
>> all my entity-instances to one resource. Does your experience teach
>> you a better approach? You'll for sure answer 'that depends' but a
>> good few hints would help a lot.
> That depends ;-)
>
> My tip:
> Don't apply structure to anything until you discover an urgent need for
> a certain structure.
> If you structure something without requirements you run into danger that
> the chosen structure doesn't meet the requirements when they come.
> When you have requirements you'll know how to transform them into
> appropriate design most of the time.
>
> Too general?
> Then I need more input ;-)
>
> Cheers
> /Eike
>
>
>>
>> Thanks + Cheers
>> André
>>
>> Eike Stepper wrote:
>>> Hi André,
>>>
>>> Comment below...
>>>
>>>
>>>
>>> André Dietisheim schrieb:
>>>> Hi Eike,
>>>>
>>>> Thanks, that enligthens me... so a classical usage scenario (like
>>>> adding records to a RDBMS) is adding/modifying/removing resources in
>>>> CDO, right?
>>> yes, generally you add, modify and remove objects and object trees,
>>> but resources are also objects ;-)
>>>
>>>> Searching objects is done by iterating through records and searching
>>>> the objects stored in it?
>>> /model-centric vs. database-centric/:
>>>
>>> I don't like the terms schemas, records, rows, columns, etc. very
>>> much in conjunction with modeling ;-)
>>> From a usual application's point of view there are models (packages)
>>> and there are instances of these models (objects and resources).
>>> Your application integrates with EMF to get access to these modeling
>>> concepts. CDO integrates with EMF at client side to add the concepts
>>> of transactionality and persistence.
>>> CDO can transfer the EMF concepts and theCDO concepts over the
>>> network to a model repository.
>>> A CDO model repository must have a backend storage (IStore)
>>> configured and it only depends on the implementation of this IStore
>>> how the EMF and CDO concepts are mapped to persistent data (in the
>>> case of the MEMStore this even doesn't need to be really persistent).
>>> This IStore can implement a mapping to an RDB (through Hibernate or
>>> native JDBC), to a flat file system, to an OODB and, and, and...
>>>
>>> So, back to your question, "searching" (given that you mean "my
>>> application searches") is primarily done by using the modeling
>>> concepts, that is "navigating" through object graphs.
>>> One out-of-the-box exception is loading a resource by giving an
>>> externally well-known name.
>>> Another exception is indeed server-side searching and Simon is
>>> working on this topic.
>>> It will at least partially be store-dependent, although we might be
>>> able to have common query languages like ocl and xpath available in
>>> the core repository as well.
>>>
>>> Is this what you intended to ask?
>>>
>>>
>>>> As far as I understood CDO for now, you may put different types in a
>>>> resource.
>>> What are "types" here? Do you mean object of different classes? Then,
>>> yes ;-)
>>>
>>>> Is there any good pratice to split objects to different resources?
>>> Hmm, good question and surely not the first time this question comes
>>> up ;-)
>>> For example in file based model persistence (the default with XML)
>>> you quickly reach limits with huge resources and you naturally start
>>> thinking about how to cut the object tree into separate containment
>>> trees (==resources). I think it's mainly driven by the restriction of
>>> lazy loading to non-containement references. Well, this is only
>>> partially true since EMF has containment proxies nowadays, as well.
>>> With CDO this basic restriction is no longer there for CDO native
>>> models (derived from CDOObjectImpl).
>>> *All* references, containment or not, are loaded on demand and are
>>> even unloaded transparently on demand.
>>> So the scalability characteristics also don't seem to make good
>>> arguments for a certain strategy to partition the object tree.
>>>
>>> At least as long as the query feature is not fully available I'd say
>>> the best criterium is "Do I need random access to an object? Then I
>>> put it into a named resource."
>>> Btw. if you don't care to externally store an object ID (as you would
>>> have to do for a resource path), you can also directly access objects
>>> by id.
>>>
>>> Cheers
>>> /Eike
>>>
|
|
|
| Re: [CDO] Re: what is a resource? [message #420133 is a reply to message #420132] |
Wed, 18 June 2008 17:34 |
|
André Dietisheim schrieb:
> Hi Eike
>
> I knew that it's for sure (and it does not depend) that you'll say
> that it depends ;-) )
> I worked mostly being database-centric and mapped that view to the
> OO-world so far.
> Good hint, not to apply any structure if it's not necessar, it follows
> agile principles. So I'll probably start my putting all my model
> instances to 1 resource.
> To show my use case:
> I'll have customers that own locations. Those locations will contains
> phones and those phones will have features. That looks (to
> unexperienced modeler I am) like a single resource that contains
> several customer objects that have references to location-objects and
> so on.
That looks like a reasonable start.
> I'll catch up as soon as I get more concrete data and requirements.
> Thanks a lot so far!
You're welcome ;-)
Cheers
/Eike
>
> Cheers
> André
>
> Eike Stepper wrote:
>> André Dietisheim schrieb:
>>> Hi Eike
>>>
>>> wow, extensive explanations. I'll have to switch context and in
>>> object graphs instead of relational organisation of the data. What I
>>> try to answer is if it's compliant to good (modelling/CDO) pratices
>>> to add all my entity-instances to one resource. Does your experience
>>> teach you a better approach? You'll for sure answer 'that depends'
>>> but a good few hints would help a lot.
>> That depends ;-)
>>
>> My tip:
>> Don't apply structure to anything until you discover an urgent need
>> for a certain structure.
>> If you structure something without requirements you run into danger
>> that the chosen structure doesn't meet the requirements when they come.
>> When you have requirements you'll know how to transform them into
>> appropriate design most of the time.
>>
>> Too general?
>> Then I need more input ;-)
>>
>> Cheers
>> /Eike
>>
>>
>>>
>>> Thanks + Cheers
>>> André
>>>
>>> Eike Stepper wrote:
>>>> Hi André,
>>>>
>>>> Comment below...
>>>>
>>>>
>>>>
>>>> André Dietisheim schrieb:
>>>>> Hi Eike,
>>>>>
>>>>> Thanks, that enligthens me... so a classical usage scenario (like
>>>>> adding records to a RDBMS) is adding/modifying/removing resources
>>>>> in CDO, right?
>>>> yes, generally you add, modify and remove objects and object trees,
>>>> but resources are also objects ;-)
>>>>
>>>>> Searching objects is done by iterating through records and
>>>>> searching the objects stored in it?
>>>> /model-centric vs. database-centric/:
>>>>
>>>> I don't like the terms schemas, records, rows, columns, etc. very
>>>> much in conjunction with modeling ;-)
>>>> From a usual application's point of view there are models
>>>> (packages) and there are instances of these models (objects and
>>>> resources).
>>>> Your application integrates with EMF to get access to these
>>>> modeling concepts. CDO integrates with EMF at client side to add
>>>> the concepts of transactionality and persistence.
>>>> CDO can transfer the EMF concepts and theCDO concepts over the
>>>> network to a model repository.
>>>> A CDO model repository must have a backend storage (IStore)
>>>> configured and it only depends on the implementation of this IStore
>>>> how the EMF and CDO concepts are mapped to persistent data (in the
>>>> case of the MEMStore this even doesn't need to be really
>>>> persistent). This IStore can implement a mapping to an RDB (through
>>>> Hibernate or native JDBC), to a flat file system, to an OODB and,
>>>> and, and...
>>>>
>>>> So, back to your question, "searching" (given that you mean "my
>>>> application searches") is primarily done by using the modeling
>>>> concepts, that is "navigating" through object graphs.
>>>> One out-of-the-box exception is loading a resource by giving an
>>>> externally well-known name.
>>>> Another exception is indeed server-side searching and Simon is
>>>> working on this topic.
>>>> It will at least partially be store-dependent, although we might be
>>>> able to have common query languages like ocl and xpath available in
>>>> the core repository as well.
>>>>
>>>> Is this what you intended to ask?
>>>>
>>>>
>>>>> As far as I understood CDO for now, you may put different types in
>>>>> a resource.
>>>> What are "types" here? Do you mean object of different classes?
>>>> Then, yes ;-)
>>>>
>>>>> Is there any good pratice to split objects to different resources?
>>>> Hmm, good question and surely not the first time this question
>>>> comes up ;-)
>>>> For example in file based model persistence (the default with XML)
>>>> you quickly reach limits with huge resources and you naturally
>>>> start thinking about how to cut the object tree into separate
>>>> containment trees (==resources). I think it's mainly driven by the
>>>> restriction of lazy loading to non-containement references. Well,
>>>> this is only partially true since EMF has containment proxies
>>>> nowadays, as well.
>>>> With CDO this basic restriction is no longer there for CDO native
>>>> models (derived from CDOObjectImpl).
>>>> *All* references, containment or not, are loaded on demand and are
>>>> even unloaded transparently on demand.
>>>> So the scalability characteristics also don't seem to make good
>>>> arguments for a certain strategy to partition the object tree.
>>>>
>>>> At least as long as the query feature is not fully available I'd
>>>> say the best criterium is "Do I need random access to an object?
>>>> Then I put it into a named resource."
>>>> Btw. if you don't care to externally store an object ID (as you
>>>> would have to do for a resource path), you can also directly access
>>>> objects by id.
>>>>
>>>> Cheers
>>>> /Eike
>>>>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
Goto Forum:
Current Time: Tue Apr 16 11:33:25 GMT 2024
Powered by FUDForum. Page generated in 0.04212 seconds |
] 
Search
Help
Register
Login
Home
